UNIT-2
Threads
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 (or heavyweight) 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. The
below diagram illustrates the difference between a traditional single-threaded process and a multithreaded
process.
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. Applications can also be designed to leverage
processing capabilities on multicore systems. Such applications can perform several CPU-
intensive tasks in parallel across the multiple computing cores.
In certain situations, a single application may be required to perform several similar tasks.
For example, a web server accepts client requests for web pages, images, sound, and so forth. A
busy web server may have several (perhaps thousands of) clients concurrently accessing it. If the
web server ran as a traditional single-threaded process, it would be able to service only one client
at a time, and a client might have to wait a very long time for its request to be serviced.
When a request is made, rather than creating another process, the server creates a new
thread to service the request and resume listening for additional requests. This is illustrated below.
1
,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.
2
, Ultimately, a relationship must exist between user threads and kernel threads. Three common ways
of establishing such a relationship: the many-to-one model, the one-to-one model, and the many-
to many model.
1. Many-to-One Model
The many-to-one model maps many user-level threads to one kernel thread. Thread management
is done by the thread library in user space, so it is efficient. 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.
2. One-to-One Model
The one-to-one model 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.
3. Many-to-Many Model
3
Threads
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 (or heavyweight) 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. The
below diagram illustrates the difference between a traditional single-threaded process and a multithreaded
process.
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. Applications can also be designed to leverage
processing capabilities on multicore systems. Such applications can perform several CPU-
intensive tasks in parallel across the multiple computing cores.
In certain situations, a single application may be required to perform several similar tasks.
For example, a web server accepts client requests for web pages, images, sound, and so forth. A
busy web server may have several (perhaps thousands of) clients concurrently accessing it. If the
web server ran as a traditional single-threaded process, it would be able to service only one client
at a time, and a client might have to wait a very long time for its request to be serviced.
When a request is made, rather than creating another process, the server creates a new
thread to service the request and resume listening for additional requests. This is illustrated below.
1
,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.
2
, Ultimately, a relationship must exist between user threads and kernel threads. Three common ways
of establishing such a relationship: the many-to-one model, the one-to-one model, and the many-
to many model.
1. Many-to-One Model
The many-to-one model maps many user-level threads to one kernel thread. Thread management
is done by the thread library in user space, so it is efficient. 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.
2. One-to-One Model
The one-to-one model 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.
3. Many-to-Many Model
3
