Page 354 - DCAP103_Principle of operating system

Unit 12: Processes and Threads in Windows

although protected from tampering by the memory management unit hardware. A process has Notes
a process ID, one or more threads, a list of handles (managed in kernel mode), and an access
token holding its security information. Processes are created using a Win32 call that takes as
its input the name of an executable file, which defines the initial contents of the address space
and creates the first thread.

Every process starts out with one thread, but new ones can be created dynamically. Threads
forms the basis of CPU scheduling as the operating system always selects a thread to run,
not a process. Consequently, every thread has a state (ready, running, blocked, etc.), whereas
processes do not have states. Threads can be created dynamically by a Win32 call that specifies
the address within the enclosing process’ address space it is to start running at. Every thread
has a thread ID, which is taken from the same space as the process IDs, so an ID can never be
in use for both: a process and a thread at the same time. Process and thread IDs are multiples
of four so they can be used as byte indices into kernel tables, the same as other objects.
A thread normally runs in user mode, but when it makes a system call it switches to kernel
mode and continues to run as the same thread with the same properties and limits it had in user
mode. Each thread has two stacks, one for use when it is in user mode and one for use when it
is in kernel mode. In addition to a state, an ID, and two stacks, every thread has a context (in
which to save its registers when it is not running), a private area for its own local variables, and
possibly its own access token. If it has its own access token, this one overrides the process access
token in order to let client threads pass their access rights to server threads who are doing work
for them. When a thread is finished executing, it can exit. When the last thread still active in a
process exit, the process terminates.
It is important to realize that threads are a scheduling concept, not a resource ownership concept.
Any thread is able to access all the objects that belong to its process. All it has to do is to grab
the handle and to make the appropriate Win32 call. There is no restriction on a thread that it
cannot access an object because a different thread created or opened it. The system does not
even keep track of which thread created which object. Once an object handle has been put in a
process handle table, any thread in the process can use it.
In addition to the normal threads that run within user processes, Windows 2000 has a number
of daemon threads that run only in kernel space and are not associated with any user process
(they are associated with the special system or idle processes). Some perform administrative
tasks, such as writing dirty pages to the disk, while others form a pool that can be assigned to a
component of the executive or a driver that needs to get some work done asynchronously in the
background. We will study some of these threads later when we come to the memory management.

Switching threads in Windows 2000 is relatively expensive because doing a thread switch
requires entering and later leaving kernel mode. To provide very lightweight pseudoparallelism,
Windows 2000 provides fibers, which are like threads, but are scheduled in user space by the
program that created them (or its run-time system). Each thread can have multiple fibers, the
same way a process can have multiple threads, except that when a fiber logically blocks, it puts
itself on the queue of blocked fibers and selects another fiber to run in the context of its thread.
The operating system is not aware of this transition because the thread keeps on running, even
though it may be first running one fiber, then another. In fact, the operating system knows
nothing at all about fibers, so there are no executive objects relating to fibers, as there are for
jobs, processes, and threads. There are also no true system calls for managing fibers. However,
there are Win32 API calls. These are among the Win32 API calls that do not make system calls,
which we mentioned during the discussion of Figure 11.7 in previous Unit. The relationship
between jobs, processes, and threads is illustrated in Figure 12.2.

LOVELY PROFESSIONAL UNIVERSITY 347