Threads

• Thread is an execution unit

• own program counter ->which instruction to execute
• a stack->history of execution
• set of registers->Current working variables
 Motivation

• Most modern applications are multithreaded

• Threads run within application
• Multiple tasks with the application can be
implemented by separate threads
– 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
 Process and Threads
• Process • Thread
– A Process simply means any – Thread simply means a segment
program in execution. of a process.
– The process consumes more – Thread consumes fewer
resources resources.
– The process requires more time for – Thread requires comparatively
creation. less time for creation than
process.
– The process is a heavyweight – Thread is known as a lightweight
process process
– The process takes more time to – The thread takes less time to
terminate terminate.
– Processes have independent data – A thread mainly shares the data
and code segments segment, code segment, files,
– The process takes more time for etc. with its peer threads.
context switching. – The thread takes less time for
– Communication between context switching
processes needs more time as
– Communication between
compared to thread.
threads needs less time as
compared to processes.
Multithreaded Server Architecture
 Benefits

• Responsiveness – may allow program to continue

execution even if part of it process is blocked or is
performing lengthy operation
• Resource Sharing – threads share resources of process,
easier than shared memory or message passing
• Economy – cheaper than process creation, thread shares
the resources of the process to which they belong ,its is
more economical to create and context switching
• Scalability –even greater in a multiprocessor architectures
• Context Switching is smooth. Context switching refers to
the procedure followed by the CPU to change from one
task to another.
• Enhanced Throughput of the system.
 Multicore Programming

• Multicore or multiprocessor challenges include:

– Dividing activities
– Balance
– Data splitting
– Data dependency
– Testing and debugging
• Parallelism implies a system can perform more
than one task simultaneously
• Concurrency supports more than one task making
progress
– Single processor / core, scheduler providing concurrency
 Multicore Programming (Cont.)

• Types of parallelism
– Data parallelism – distributes subsets of the
same data across multiple cores, same
operation on each
– Task parallelism – distributing threads across
cores, each thread performing unique
operation
– CPUs have cores as well as hardware threads
– Consider Oracle SPARC T4 with 8 cores, and 8
hardware threads per core
 Concurrency vs. Parallelism
 Concurrent execution on single-core system:

 Parallelism on a multi-core system:

 Types of Thread
• User Level threads • Kernel Level Threads
– These threads are implemented – These threads are implemented by
by users. Operating systems
– These threads are not recognized – These threads are recognized by
operating systems
by operating systems
– In Kernel Level threads, hardware
– In User Level threads, the support is needed.
Context switch requires no – These threads are mainly designed as
hardware support. independent threads.
– These threads are mainly – On the other hand, if one kernel
designed as dependent threads. thread performs a blocking operation
then another thread can continue the
– In User Level threads, if one user- execution.
level thread performs a blocking – Eg:
operation then the entire • WindowsSolaris
process will be blocked. • Linux
– Eg: Java thread, POSIX threads. • Tru64 UNIX
– Implementation of User Level • Mac OS X
thread is done by a thread
library and is easy. – While the Implementation of the
kernel-level thread is done by the
operating system and is complex.
 Multithreading Models

• Many-to-One

• One-to-One

• Many-to-Many
 Many-to-One

• Many user-level threads mapped to

single kernel thread
• Thread management is done by the
thread library in user space, so it is
efficient
• One thread blocking causes all to block
• Multiple threads may not run in
parallel on multicore system because
only one may be in kernel at a time
• Few systems currently use this model
• Examples:
– Solaris Green Threads
– GNU Portable Threads
 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
 Many-to-Many Model
• Allows many user level
threads to be mapped to
many kernel threads
• Allows the operating
system to create a
sufficient number of kernel
threads
• Solaris prior to version 9
• Windows with the
ThreadFiber package
 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
 Threading Issues

1. Semantics of fork() and exec() system

calls change in multithreaded Program
2. Signal handling
1. Synchronous and asynchronous
3. Thread cancellation of target thread
1. Asynchronous or deferred
4. Thread-local storage
5. Scheduler Activations
 1.Semantics of fork() and exec()

• fork() system call is used to create a

separate, duplicate process
• 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
 2.Signal Handling
• Signals are used in UNIX systems to notify a process
that a particular event has occurred.
• All signals ,whether synchronous or asynchronous,
follow the same pattern
• A signal handler is used to process signals
– Signal is generated by particular event
– Signal is delivered to a process
– Signal is handled by one of two signal handlers:
• default
• user-defined
Possible handlers:
• 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
 Signal Handling (Cont.)
– Signals are handled in different ways
• Some signals are simply ignored
• Others are handled by terminating the program
– Delivering signals is more complicated in
multithreaded programs
Options:
• 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
 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 checks whether if it should be terminate,
allowing it an opportunity to terminate itself in orderly
• Pthread code to create and cancel a thread:
 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 Cancellation 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
 Thread-Local Storage

• Threads belonging to a process share the data of the

process.
• This data sharing provides one of the benefits of
multithreaded programming.
• 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)
• TLS 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
 Scheduler Activations
• Communication between kernel and thread library
• 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