Operating System

By
Mr. Parag R. Sali
Lecturer
Department of Computer Technology
SNJB’s Shri. Hiralal Hastimal ( Jain Brothers)
Polytechnic, Chandwad
Program Name: Computer Engineering Group
Program Code : CO/CM/IF/CW
Semester : Fifth
Course Title : Operating System
Course Code : 22516

3.4 Threads
 Thread

A thread is a basic unit of CPU utilization; it comprises a thread ID, a program

counter, a register set, and a stack. It shares with other threads belonging to
the same process its code section, data section, and other operating-system
resources, such as open files and signals.
A traditional process has a single thread of control. If a process has multiple
threads of control, it can perform more than one task at a time. Figure
illustrates the difference between a traditional single-threaded process and a
multithreaded process.
Figure Single-threaded and multithreaded processes.
Most software applications that run on modern computers are multithreaded.
An application typically is implemented as a separate process with several
threads of control. A web browser might have one thread display images or text
while another thread retrieves data from the network, for example. A word
processor may have a thread for displaying graphics, another thread for
responding to keystrokes from the user, and a third thread for performing
spelling and grammar checking in the background.
 Benefits
The benefits of multithreaded programming can be broken down into four major
categories:
1. Responsiveness. Multithreading an interactive application may allow a program
to continue running even if part of it is blocked or is performing a lengthy
operation, thereby increasing responsiveness to the user. This quality is especially
useful in designing user interfaces. For instance, consider what happens when a
user clicks a button that results in the performance of a time-consuming operation.
A single-threaded application would be unresponsive to the user until the
operation had completed. In contrast, if the time-consuming operation is
performed in a separate thread, the application remains responsive to the user.
2. Resource sharing. Processes can only share resources through techniques
such as shared memory and message passing. Such techniques must be explicitly
arranged by the programmer. However, threads share the memory and the
resources of the process to which they belong by default. The benefit of sharing
code and data is that it allows an application to have several different threads of
activity within the same address space.
3. Economy. Allocating memory and resources for process creation is costly.
Because threads share the resources of the process to which they belong, it is
more economical to create and context-switch threads. Empirically gauging the
difference in overhead can be difficult, but in general it is significantly more time
consuming to create and manage processes than threads. In Solaris, for example,
creating a process is about thirty times slower than is creating a thread, and
context switching is about five times slower.
4. Scalability. The benefits of multithreading can be even greater in a
multiprocessor architecture, where threads may be running in parallel
on different processing cores. A single-threaded process can run on
only one processor, regardless how many are available.
 Multithreading Models
Support for threads may be provided either at the user level, for user threads,
or by the kernel, for kernel threads. User threads are supported above the
kernel and are managed without kernel support, whereas kernel threads are
supported and managed directly by the operating system. Virtually all
contemporary operating systems—including Windows, Linux, Mac OS X, and
Solaris— support kernel threads.
Ultimately, a relationship must exist between user threads and kernel threads.
In this section, we look at three common ways of establishing such a
relationship: the many-to-one model, the one-to-one model, and the many to
many model.
 Many-to-One Model
The many-to-one model (Figure 1) maps many user-level threads to one kernel
thread. Thread management is done by the thread library in user space,
so it is efficient (thread libraries). However, the entire process will block if a
thread makes a blocking system call. Also, because only one thread can access
the kernel at a time, multiple threads are unable to run in parallel on
multicore systems. Green threads—a thread library available for Solaris
systems and adopted in early versions of Java—used the many-to-one model.
However, very few systems continue to use the model because of its inability
to take advantage of multiple processing cores.
Figure 1 Many-to-one model.
 One-to-One Model
The one-to-one model (Figure 2) maps each user thread to a kernel thread. It
provides more concurrency than the many-to-one model by allowing another
thread to run when a thread makes a blocking system call. It also allows
multiple threads to run in parallel on multiprocessors. The only drawback to this
model is that creating a user thread requires creating the corresponding kernel
thread. Because the overhead of creating kernel threads can burden the
performance of an application, most implementations of this model restrict the
number of threads supported by the system. Linux, along with the family of
Windows operating systems, implement the one-to-one model.
Figure 2 One-to-one model.
 Many-to-Many Model
The many-to-many model (Figure 3) multiplexes many user-level threads to a smaller
or equal number of kernel threads. The number of kernel threads may be specific to
either a particular application or a particular machine (an application may be
allocated more kernel threads on a multiprocessor than on a single processor).
Let’s consider the effect of this design on concurrency. Whereas the many to- one
model allows the developer to create as many user threads as she wishes, it does
not result in true concurrency, because the kernel can schedule only one thread at a
time. The one-to-one model allows greater concurrency, but the developer has to be
careful not to create too many threads within an application (and in some instances
may be limited in the number of threads she can create). The many-to-many model
suffers from neither of these shortcomings: developers can create as many user
threads as necessary, and the corresponding kernel threads can run in parallel on a
multiprocessor. Also, when a thread performs a blocking system call, the kernel can
schedule another thread for execution.
Figure 3 Many-to-many model.
One variation on the many-to-many model still multiplexes many user level
threads to a smaller or equal number of kernel threads but also allows a user
level thread to be bound to a kernel thread. This variation is sometimes referred
to as the two-level model (Figure 4). The Solaris operating system supported the
two-level model in versions older than Solaris 9. However, beginning with Solaris
9, this system uses the one-to-one model.
Figure 4 Two-level model.