THREADS, SMP, AND MICROKERNELS

The Thread

The discussion so far has presented the concept of a process as embodying two
characteristics:
• Resource ownership: A process includes a virtual address space to hold the
process image; recall from Chapter 3 that the process image is the collection of
program, data, stack, and attributes defined in the process control block. From
time to time, a process may be allocated control or ownership of resources,
such as main memory, I/O channels, I/O devices, and files. The OS performs a
protection function to prevent unwanted interference between processes with
respect to resources.
• Scheduling/execution: The execution of a process follows an execution path
(trace) through one or more programs (e.g., Figure 1.5 and Figure 1.26). This
execution may be interleaved with that of other processes.Thus, a process has
an execution state (Running, Ready, etc.) and a dispatching priority and is the
entity that is scheduled and dispatched by the OS.
Some thought should convince the reader that these two characteristics are independent
and could be treated independently by the OS.This is done in a number
of operating systems, particularly recently developed systems.To distinguish the two
characteristics, the unit of dispatching is usually referred to as a thread or lightweight
process, while the unit of resource ownership is usually still referred to as a process
or task.1
Multithreading
Multithreading refers to the ability of an OS to support multiple, concurrent paths of
execution within a single process.The traditional approach of a single thread of execution
per process, in which the concept of a thread is not recognized, is referred to

as a single-threaded approach. The two arrangements shown in the left half of
Figure 4.1 are single-threaded approaches. MS-DOS is an example of an OS that
supports a single user process and a single thread. Other operating systems, such as
some variants of UNIX, support multiple user processes but only support one
thread per process.The right half of Figure 4.1 depicts multithreaded approaches.A
Java run-time environment is an example of a system of one process with multiple
threads. Of interest in this section is the use of multiple processes, each of which support
multiple threads.This approach is taken in Windows, Solaris, and many modern
versions of UNIX, among others. In this section we give a general description of
multithreading; the details of the Windows, Solaris, and Linux approaches are discussed
later in this chapter.
In a multithreaded environment, a process is defined as the unit of resource
allocation and a unit of protection.The following are associated with processes:
• A virtual address space that holds the process image
• Protected access to processors, other processes (for interprocess communication),
files, and I/O resources (devices and channels)
Within a process, there may be one or more threads, each with the following:
• A thread execution state (Running, Ready, etc.).
• A saved thread context when not running; one way to view a thread is as an independent
program counter operating within a process.

• An execution stack.
• Some per-thread static storage for local variables.
• Access to the memory and resources of its process, shared with all other
threads in that process.
Figure 4.2 illustrates the distinction between threads and processes from the
point of view of process management. In a single-threaded process model (i.e., there
is no distinct concept of thread), the representation of a process includes its process
control block and user address space, as well as user and kernel stacks to manage
the call/return behavior of the execution of the process.While the process is running,
it controls the processor registers. The contents of these registers are saved
when the process is not running. In a multithreaded environment, there is still a single
process control block and user address space associated with the process,
but now there are separate stacks for each thread, as well as a separate control block
for each thread containing register values, priority, and other thread-related state
information.
Thus, all of the threads of a process share the state and resources of that
process. They reside in the same address space and have access to the same data.
When one thread alters an item of data in memory, other threads see the results if
and when they access that item. If one thread opens a file with read privileges, other
threads in the same process can also read from that file.
The key benefits of threads derive from the performance implications:
1. It takes far less time to create a new thread in an existing process than to create
a brand-new process. Studies done by the Mach developers show that
thread creation is ten times faster than process creation in UNIX [TEVA87].
2. It takes less time to terminate a thread than a process.
3. It takes less time to switch between two threads within the same process than to
switch between processes.
4. Threads enhance efficiency in communication between different executing
programs. In most operating systems, communication between independent
processes requires the intervention of the kernel to provide protection and the
mechanisms needed for communication. However, because threads within the
same process share memory and files, they can communicate with each other
without invoking the kernel.
Thus, if there is an application or function that should be implemented as a set
of related units of execution, it is far more efficient to do so as a collection of threads
rather than a collection of separate processes.
An example of an application that could make use of threads is a file server.
As each new file request comes in, a new thread can be spawned for the file management
program. Because a server will handle many requests, many threads will be
created and destroyed in a short period. If the server runs on a multiprocessor computer,
then multiple threads within the same process can be executing simultaneously
on different processors. Further, because processes or threads in a file server
must share file data and therefore coordinate their actions, it is faster to use threads
and shared memory than processes and message passing for this coordination.
The thread construct is also useful on a single processor to simplify the structure
of a program that is logically doing several different functions.