Chapter 4: Threads

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
 Chapter 4: Threads
 Overview
 Multithreading Models
 Threading Issues

Operating System Concepts – 9th Edition 4.2 Silberschatz, Galvin and Gagne ©2013
 Objectives
 To introduce the notion of a thread—a fundamental unit of CPU
utilization that forms the basis of multithreaded computer
systems
 To discuss the APIs for the Pthreads, Windows, and Java
thread libraries
 To explore several strategies that provide implicit threading
 To examine issues related to multithreaded programming
 To cover operating system support for threads in Windows and
Linux

Operating System Concepts – 9th Edition 4.3 Silberschatz, Galvin and Gagne ©2013
 Overview
 A thread is a basic unit of CPU utilization.

Thread ID Program Register set stack

counter

It shares with other threads belonging to the same process its code
section, data section, and other operating-system resources.

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.

Operating System Concepts – 9th Edition 4.4 Silberschatz, Galvin and Gagne ©2013
 Single and Multithreaded Processes

Operating System Concepts – 9th Edition 4.5 Silberschatz, Galvin and Gagne ©2013
 Motivation

 Most software applications that run on modern computers are

multithreaded.
 Threads run within application
 Multiple tasks with the application can be implemented by separate threads
 A web browser might have one thread
 Update display
 Fetch data
 Spell checking
 Answer a network request
 Process creation is heavy-weight while thread creation is light-weight
 Can simplify code, increase efficiency
 Kernels are generally multithreaded

Operating System Concepts – 9th Edition 4.6 Silberschatz, Galvin and Gagne ©2013
 Motivation

 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.
 One solution is to have the server run as a single process that accepts
requests.
 Process creation is time consuming and resource intensive.
 It is generally more efficient to use one process that contains multiple
threads.

Operating System Concepts – 9th Edition 4.7 Silberschatz, Galvin and Gagne ©2013
 Multithreaded Server Architecture
Threads also play a vital role in remote procedure call (RPC) systems

Most operating-system kernels are now multithreaded.

Several threads operate in the kernel, and each thread performs a

specific task, such as
1) managing devices
2) managing memory
3) interrupt handling.

Operating System Concepts – 9th Edition 4.8 Silberschatz, Galvin and Gagne ©2013
 Benefits

 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.
 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.

 Resource Sharing – Processes can only share resources

through techniques such as shared memory and message
passing.
 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.


Operating System Concepts – 9th Edition 4.9 Silberschatz, Galvin and Gagne ©2013
 Benefits
 Economy – Allocating memory and resources for process creation is costly.
 It is more economical to create and context-switch threads.
 For example, creating a process is about thirty times

 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. We explore this issue further in the following section.

Operating System Concepts – 9th Edition 4.10 Silberschatz, Galvin and Gagne ©2013
 Multithreading Models

A relationship must exist between user threads and kernel threads

Many-to-One model

One-to-One model

Many-to-Many model

Operating System Concepts – 9th Edition 4.11 Silberschatz, Galvin and Gagne ©2013
 Many-to-One

 Many user-level threads mapped to

single kernel thread
 One thread blocking causes all to block
 Multiple threads may not run in parallel
on muticore system because only one
may be in kernel at a time
 Few systems currently use this model
 Examples:
 Solaris Green Threads
 GNU Portable Threads

Operating System Concepts – 9th Edition 4.12 Silberschatz, Galvin and Gagne ©2013
 One-to-One
 Each user-level thread maps to kernel thread
 Creating a user-level thread creates a kernel thread
 More concurrency than many-to-one
 Number of threads per process sometimes
restricted due to overhead
 Examples
 Windows
 Linux
 Solaris 9 and later

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
Operating System Concepts – 9th Edition 4.13 Silberschatz, Galvin and Gagne ©2013
 Many-to-Many Model
 Allows many user level threads to be mapped to a smaller or equal number
of kernel threads.
 Allows the operating system to create a sufficient number of kernel threads
 Solaris prior to version 9
 Windows with the ThreadFiber package

 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.
The one-to-one model allows greater concurrency

Operating System Concepts – 9th Edition 4.14 Silberschatz, Galvin and Gagne ©2013
 Two-level Model
 Similar to M:M, except that it allows a user thread to be
bound to kernel thread
 Examples
 IRIX
 HP-UX
 Tru64 UNIX
 Solaris 8 and earlier

Operating System Concepts – 9th Edition 4.15 Silberschatz, Galvin and Gagne ©2013
 Threading Issues
 Semantics of fork() and exec() system calls
 Signal handling
 Synchronous and asynchronous
 Thread cancellation of target thread
 Asynchronous or deferred
 Thread-local storage
 Scheduler Activations

Operating System Concepts – 9th Edition 4.16 Silberschatz, Galvin and Gagne ©2013
 Semantics of fork() and exec()

 Does fork()duplicate only the calling thread or all

threads?
 Some UNIXes have two versions of fork
 exec() usually works as normal – replace the running
process including all threads

Operating System Concepts – 9th Edition 4.17 Silberschatz, Galvin and Gagne ©2013
 Signal Handling
 Signals are used in UNIX systems to notify a process that a
particular event has occurred.
 A signal handler is used to process signals
1. Signal is generated by particular event
2. Signal is delivered to a process
3. Signal is handled by one of two signal handlers:
1. default
2. user-defined
 Every signal has default handler that kernel runs when
handling signal
 User-defined signal handler can override default
 For single-threaded, signal delivered to process

Operating System Concepts – 9th Edition 4.18 Silberschatz, Galvin and Gagne ©2013
 Signal Handling (Cont.)
 Where should a signal be delivered for multi-threaded?
 Deliver the signal to the thread to which the signal
applies
 Deliver the signal to every thread in the process
 Deliver the signal to certain threads in the process
 Assign a specific thread to receive all signals for the
process

Operating System Concepts – 9th Edition 4.19 Silberschatz, Galvin and Gagne ©2013
 Thread Cancellation
 Terminating a thread before it has finished
 Thread to be canceled is target thread
 Two general approaches:
 Asynchronous cancellation terminates the target thread
immediately
 Deferred cancellation allows the target thread to periodically
check if it should be cancelled
 Pthread code to create and cancel a thread:

Operating System Concepts – 9th Edition 4.20 Silberschatz, Galvin and Gagne ©2013
 Thread Cancellation (Cont.)
 Invoking thread cancellation requests cancellation, but actual
cancellation depends on thread state

 If thread has cancellation disabled, cancellation remains pending

until thread enables it
 Default type is deferred
 Cancellation only occurs when thread reaches cancellation
point
 I.e. pthread_testcancel()
 Then cleanup handler is invoked
 On Linux systems, thread cancellation is handled through signals

Operating System Concepts – 9th Edition 4.21 Silberschatz, Galvin and Gagne ©2013
 Thread-Local Storage

 Thread-local storage (TLS) allows each thread to have its

own copy of data
 Useful when you do not have control over the thread creation
process (i.e., when using a thread pool)
 Different from local variables
 Local variables visible only during single function
invocation
 TLS visible across function invocations
 Similar to static data
 TLS is unique to each thread

Operating System Concepts – 9th Edition 4.22 Silberschatz, Galvin and Gagne ©2013
 Scheduler Activations
 Both M:M and Two-level models require communication to maintain the
appropriate number of kernel threads allocated to the application
 Typically use an intermediate data structure between user and kernel
threads – lightweight process (LWP)
 Appears to be a virtual processor on which process can schedule
user thread to run
 Each LWP attached to kernel thread
 How many LWPs to create?
 Scheduler activations provide upcalls - a communication mechanism
from the kernel to the upcall handler in the thread library
 This communication allows an application to maintain the correct number
kernel threads

Operating System Concepts – 9th Edition 4.23 Silberschatz, Galvin and Gagne ©2013
 Scheduler Activations
 A final issue to be considered with multithreaded programs concerns
communication between the kernel and the thread library.

 Many systems implementing either the many-to-many or the two-level

model place an intermediate data structure between the user and kernel
threads.

 This data structure—typically known as a lightweight process, or LWP

Operating System Concepts – 9th Edition 4.24 Silberschatz, Galvin and Gagne ©2013
 Scheduler Activations
 Both M:M and Two-level models require
communication to maintain the appropriate
number of kernel threads allocated to the
application
 Typically use an intermediate data structure
between user and kernel threads – lightweight
process (LWP)
 Appears to be a virtual processor on which
process can schedule user thread to run
 Each LWP attached to kernel thread
 How many LWPs to create?
 Scheduler activations provide upcalls - a
communication mechanism from the kernel to
the upcall handler in the thread library
 This communication allows an application to
maintain the correct number kernel threads

Operating System Concepts – 9th Edition 4.25 Silberschatz, Galvin and Gagne ©2013
 End of Chapter 4

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013