2. Agenda for today
• Processes vs. Threads
• User vs. Kernel Threads
• Multithreading Models
• Threading Issues
• Pthreads
• Linux Threads
• Windows XP Threads
3. Process Overheads
• A full process includes numerous things:
– an address space (defining all the code and
data pages)
– OS resources and accounting information
– a “thread of control”,
• defines where the process is currently
executing
• PC, registers, and stack
Creating a new process is costly
– all of the structures (e.g., page tables) that
must be allocated
Communicating between processes is costly
– most communication goes through the OS
4. Threads and Processes
• Most operating systems therefore support two entities:
– the process,
• which defines the address space and general process attributes
– the thread,
• which defines a sequential execution stream within a process
• A thread is bound to a single process.
– For each process, however, there may be many threads.
• Threads are the unit of scheduling
• Processes are containers in which threads execute
6. Distinguishing Threads and Processes
• Makes it easier to support multithreaded applications
– Different from multiprocessing, multiprogramming, multitasking
• Concurrency (multithreading) is useful for:
– improving program structure
– Improving responsiveness
– handling concurrent events (e.g., web requests)
– building parallel programs
– sharing resources economically
– multiprocessor utilization
• Is multithreading useful even on a single processor?
7. Threads vs. Processes
• A thread has no data segment or heap
• A thread cannot live on its own, it
must live within a process
• There can be more than one thread in
a process, the first thread calls main &
has the process’s stack
• Inexpensive creation
• Inexpensive context switching
• If a thread dies, its stack is reclaimed
• A process has code/data/heap &
other segments
• A process has at least one thread
• Threads within a process share
code/data/heap, share I/O, but
each has its own stack & registers
• Expensive creation
• Expensive context switching
• If a process dies, its resources are
reclaimed & all threads die
8. User and Kernel Threads
• User threads - Thread management done
by user-level threads library, with or
without knowledge of the kernel
• Kernel threads - Threads directly
supported by the kernel:
– Windows XP/2000
– Solaris
– Linux
– Tru64 UNIX
– Mac OS X
9. (a) A user-level threads package. (b) A threads
package managed by the kernel.
User vs. Kernel Threads
Example from Tanenbaum, Modern Operating Systems 3 e,
(c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
10. Kernel Threads
• Also called Lightweight Processes (LWP)
• Kernel threads still suffer from performance
problems
• Operations on kernel threads are slow because:
– a thread operation still requires a system call
– kernel threads may be overly general
• to support needs of different users, languages, etc.
– the kernel doesn’t trust the user
• there must be lots of checking on kernel calls
11. User-Level Threads
• For speed, implement threads at the user level
• A user-level thread is managed by the run-time system
– user-level code that is linked with your program
• Each thread is represented simply by:
– PC
– Registers
– Stack
– Small control block
• All thread operations are at the user-level:
– Creating a new thread
– switching between threads
– synchronizing between threads
12. User-Level Threads
• User-level threads
– the thread scheduler is part of a library, outside the kernel
– thread context switching and scheduling is done by the library
– Can either use cooperative or pre-emptive threads
• cooperative threads are implemented by:
– CreateThread(), DestroyThread(), Yield(), Suspend(), etc.
• pre-emptive threads are implemented with a timer (signal)
– where the timer handler decides which thread to run next
13. User-Level vs. Kernel Threads
User-Level
• Managed by application
• Kernel not aware of thread
• Context switching cheap
• Can create many more
• Must be used with care
Kernel-Level
• Managed by kernel
• Consumes kernel resources
• Context switching expensive
• Number limited by kernel resources
• Simpler to use
Key issue: kernel threads provide virtual processors to user-level threads,
but if all of kernel threads block, then all user-level threads will
block even if the program logic allows them to proceed
14. Multiplexing User-Level Threads
• The user-level thread package sees a “virtual” processor(s)
– it schedules user-level threads on these virtual processors
– each “virtual” processor is implemented by a kernel thread
• The big picture:
– Create as many kernel threads as there are processors
– Create as many user-level threads as the application needs
– Multiplex user-level threads on top of the kernel-level threads
• Why not just create as many kernel-level threads as app needs?
– Context switching
– Resources
16. Many-to-One
• Many user-level threads
mapped to single kernel thread
– Fast - no system calls
required
– Few system dependencies;
portable
– No parallel execution of
threads - can’t exploit
multiple CPUs
– All threads block when one
uses synchronous I/O
• Examples:
– Solaris Green Threads
– GNU Portable Threads
17. One-to-One
• Each user-level thread maps to kernel thread
– More concurrency
– Better multiprocessor performance
– Each user thread requires creation of kernel thread
– Each thread requires kernel resources; limits number of total
threads
• Examples
– Windows NT/XP/2000
– Linux
– Solaris 9 and later
18. 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
If U < L, no benefits of
multithreading
If U > L, some threads
may have to wait for an
LWP to run
Examples:
Solaris prior to version 9
Windows NT/2000 with
the ThreadFiber package
19. Two-level Model
Similar to M:M,
except that a user
thread may be
bound to kernel
thread
Examples
IRIX
HP-UX
Tru64 UNIX
Solaris 8 and
earlier
20. Multithreading Issues
• Semantics of fork() and exec() system calls
– Does fork() duplicate only the calling thread or all threads?
• Thread cancellation
– Asynchronous vs. Deferred Cancellation
• Signal handling
– Which thread to deliver it to?
• Thread pools
– Creating new threads, unlimited number of threads
• Scheduler activations
– Maintaining the correct number of scheduler threads
21. Thread Cancellation
• Terminating a thread before it has
finished
• Two general approaches:
– Asynchronous cancellation terminates
the target thread immediately
– Deferred cancellation allows the target
thread to periodically check if it should
be cancelled
22. 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
• 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 threa to receive all signals for the
process
23. Thread Pools
• Create a number of threads in a pool
where they await work
• Advantages:
– Usually slightly faster to service a request
with an existing thread than create a
new thread
– Allows the number of threads in the
application(s) to be bound to the size of
the pool
24. Scheduler Activations
• Both M:M and Two-level models require communication to
maintain the appropriate number of kernel threads
allocated to the application
• Scheduler activations provide upcalls - a communication
mechanism from the kernel to the thread library
• This communication allows an application to maintain the
correct number kernel threads
25. Pthreads (POSIX Threads)
• A POSIX standard (IEEE 1003.1c) API
for thread creation and
synchronization
• API specifies behavior of the thread
library, implementation is up to
development of the library
• Common in UNIX operating systems
(Solaris, Linux, Mac OS X)
26. Some of the Pthreads function calls.
Example: POSIX Threads (1)
Example from Tanenbaum, Modern Operating Systems 3 e,
(c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
27. An example program using threads.
POSIX Threads (2)
. . .
Example from Tanenbaum, Modern Operating Systems 3 e,
(c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
28. Figure 2-15. An example program using threads.
POSIX Threads (3)
. . .
Example from Tanenbaum, Modern Operating Systems 3 e,
(c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639
29. Linux Threads
• Linux refers to them as tasks
rather than threads
• Thread creation is done through
clone() system call
• clone() allows a child task to
share the address space of the
parent task (process)
30. Windows XP Threads
• Implements the one-to-one mapping
• Each thread contains
– A thread id
– Register set
– Separate user and kernel stacks
– Private data storage area
• The register set, stacks, and private
storage area are known as the
context of the threads