Chapter 4: Threads
Chapter 4: Threads Overview Multithreading Models Threading Issues Pthreads Windows XP Threads Linux Threads Java Threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.2
Silberschatz, Galvin and Gagne ©2005
1
Processes Recall that a process includes many things z
An address space (defining all the code and data pages)
z
OS resources (e.g., open files, child processes) and accounting information
z
Execution state (PC, SP, regs, etc.)
Creating a new process is costly because of all of the data structures
that must be allocated and initialized z
Recall struct proc in Solaris
z
…which does not even include page tables, perhaps TLB flushing, etc.
Communicating between processes is costly because most
communication goes through the OS z
Overhead of system calls (interrupt) and copying data
Operating System Concepts – 7th edition, Jan 23, 2005
4.3
Silberschatz, Galvin and Gagne ©2005
Parallel Processes Think of a Web server example that forks off copies of itself to
handle multiple simultaneous requests z
Or any parallel program that executes on a multiprocessor
To execute these programs we need to z
Create several processes that execute in parallel
z
Cause each to map to the same address space to share data They
z
are all part of the same computation
Have the OS schedule these processes in parallel (logically or physically)
This situation is very inefficient z
Space: each process needs PCB, page tables, etc.
z
Time: create data structures, fork and copy addr space, etc.
Operating System Concepts – 7th edition, Jan 23, 2005
4.4
Silberschatz, Galvin and Gagne ©2005
2
Rethinking Processes
What is similar in these cooperating processes? z
They all share the same code and data (address space)
z
They all share the same privileges
z
They all share the same resources (files, sockets, etc.)
What don’t they share?
Key idea: Why don’t we separate the concept of a process from its execution state?
z
Each has its own execution state: PC, SP, and registers
z
Process: address space, privileges, resources, etc.
z
Execution state: PC, SP, registers
Exec state also called thread of control, or thread
A thread is bound to a single process
Threads become the unit of scheduling
Result: allow multiple executions to take place in the same process environment
z
z
Processes, however, can have multiple threads Processes are now the containers in which threads execute
Operating System Concepts – 7th edition, Jan 23, 2005
4.5
Silberschatz, Galvin and Gagne ©2005
Conclusion
A traditional (or heavyweight) process has an address space and single thread of control (process)
Modern applications are multithreaded. Each thread does a task.
z
The thread defines a sequential execution stream within a process (PC, SP, registers)
z
The process defines the address space, resources, and general process attributes (everything but threads of execution)
A thread (or lightweight process) is a basic unit of CPU utilization. It consists of: z
Program counter.
z
Register set.
z
Stack space.
Threads are useful when the application performs several similar tasks. z
Web server: Process-based or Thread-based.
Operating System Concepts – 7th edition, Jan 23, 2005
4.6
Silberschatz, Galvin and Gagne ©2005
3
Threads in a Process
Operating System Concepts – 7th edition, Jan 23, 2005
4.7
Silberschatz, Galvin and Gagne ©2005
Multithreading Multithreading: a process executing an application is divided into
multiple threads of execution. z
All threads (of the same process) run concurrently.
They share address space: code section & data section. Share other operating-system resources, such as files. z No need for process context switching Switching between threads is faster. z However, there is no protection between threads z z
one thread can read, write, or even completely wipe out another
thread’s stack since they share the same address space –
Protection is not necessary, since unlike multiple processes, threads are created by the same user to cooperate not to fight.
Note: the process is the unit of resource management, not the
thread
Operating System Concepts – 7th edition, Jan 23, 2005
4.8
Silberschatz, Galvin and Gagne ©2005
4
Single and Multithreaded Processes
Operating System Concepts – 7th edition, Jan 23, 2005
4.9
Silberschatz, Galvin and Gagne ©2005
Multithreading Benefits Responsiveness: allow an interactive application to continue
running even if part of it is blocked or is performing a lengthy operation. Resource Sharing: threads share the memory (code and data) and
the resources of the process to which they belong. z
Since they do not have any resources attached to them, threads are easier to create and destroy than processes
Economy: generally, it is much more time consuming to create and
manage processes than a thread. z
Solaris: process creation 30X slower. Context switch 5X more.
Utilization of MP Architectures: threads may be running in parallel
on different processors (A single-threaded process can only run on one CPU).
Operating System Concepts – 7th edition, Jan 23, 2005
4.10
Silberschatz, Galvin and Gagne ©2005
5
Thread Design Space Single thread /single task
Single thread/Multitask
Multithread/Single task
Multithreads/Multitasks
Operating System Concepts – 7th edition, Jan 23, 2005
4.11
Silberschatz, Galvin and Gagne ©2005
Process/Thread Separation Separating threads and processes makes it easier to support
multithreaded applications z
Creating concurrency does not require creating new processes
Concurrency (multithreading) can be very useful z
Improving program structure
z
Handling concurrent events (e.g., Web requests)
z
Writing parallel programs
So multithreading is even useful on a uniprocessor
Operating System Concepts – 7th edition, Jan 23, 2005
4.12
Silberschatz, Galvin and Gagne ©2005
6
Threads: Concurrent Servers Using fork() to create new processes to handle requests in parallel
is overkill for such a simple task Recall our forking Web server:
while (1) { int sock = accept(); if ((child_pid = fork()) == 0) { Handle client request Close socket and exit } else { Close socket } }
Operating System Concepts – 7th edition, Jan 23, 2005
4.13
Silberschatz, Galvin and Gagne ©2005
Threads: Concurrent Servers
Instead, we can create a new thread for each request web_server() { while (1) { int sock = accept(); thread_fork(handle_request, sock); // usually, a threads creates new threads by calling a library procedure, for example, thread_create. the creating thread is usually returned a thread identifier that names the new thread. } } handle_request(int sock) { Process request close(sock); }
When a thread has finished its work, it can exit by calling a library procedure, say, thread_exit. It then vanishes and is no longer schedulable
Operating System Concepts – 7th edition, Jan 23, 2005
4.14
Silberschatz, Galvin and Gagne ©2005
7
Kernel Threads
We have taken the execution aspect of a process and separated it out into threads
As such, the OS now manages threads and processes
z
To make concurrency cheaper
z
Keeps track of all the required attributes of all the threads in the system
z
All thread operations are implemented in the kernel
z
The OS schedules all of the threads in the system
z
System calls are used to manage all thread operations
OS-managed threads are called kernel-level threads or lightweight processes
Kernel threads – supported and managed directly by the operating system.
Almost all contemporary operating systems support kernel threads. z
Windows XP/2000
z
Solaris
z
Linux
z
Tru64 UNIX
z
Mac OS X
Operating System Concepts – 7th edition, Jan 23, 2005
4.15
Silberschatz, Galvin and Gagne ©2005
Kernel Thread Limitations Kernel-level threads make concurrency much cheaper than processes z
Much less state to allocate and initialize
However, for fine-grained concurrency, kernel-level threads still suffer
from too much overhead z
Thread operations still require system calls Ideally,
z
want thread operations to be as fast as a procedure call
Kernel-level threads have to be general to support the needs of all programmers, languages, runtimes, etc.
For such fine-grained concurrency, need even “cheaper” threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.16
Silberschatz, Galvin and Gagne ©2005
8
User-Level Threads To make threads cheap and fast, they need to be implemented at
user level z
Kernel-level threads are managed by the OS
z
User-level threads are managed entirely by the run-time system, above the kernel, and managed without kernel support
User-level threads are small and fast z
A thread is simply represented by a PC, registers, stack, and small thread control block (TCB)
z
Creating a new thread, switching between threads, and synchronizing threads are done via procedure call
z
User-level thread operations 100x faster than kernel threads
No
kernel involvement
As far as the kernel is concerned, it is managing ordinary, single-
threaded processes z
a user-level threads package can be implemented on an operating system that does not support threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.17
Silberschatz, Galvin and Gagne ©2005
User-Level Thread Limitations
But, user-level threads are not a perfect solution
User-level threads are invisible to the OS
z
z
They are not well integrated with the OS. For example, each process needs its own private thread table to keep track of the threads parameters and state in that process
As a result, the OS can make poor decisions z
Scheduling a process with idle threads
z
Blocking a process whose thread initiated an I/O (page read, for example), even though the process has other threads that can execute
z
Unscheduling a process with a thread holding a lock
If a thread starts running, no other thread in that process will ever run unless the first thread voluntarily gives up the CPU z
As with everything else, they are a tradeoff
Within a single process, there are no clock interrupts, making it impossible to schedule user threads round-robin fashion
Solving this requires communication between the kernel and the user-level thread manager
Operating System Concepts – 7th edition, Jan 23, 2005
4.18
Silberschatz, Galvin and Gagne ©2005
9
Kernel vs. User Threads
Kernel-level threads z
Integrated with OS (informed scheduling)
z
Slow to create, manipulate, synchronize
User-level threads z
Fast to create, manipulate, synchronize
z
Not integrated with OS (uninformed scheduling)
With user-level threads, the run-time system keeps running threads from its own process until the kernel takes the CPU away from it (or there are no ready threads left to run).
With kernel-level threads When a thread blocks, the kernel may run either another thread from the same process (if one is ready), or a thread from a different process
Understanding the differences between kernel and user-level threads is important
z
For programming (correctness, performance)
z
For test-taking
Best to use both kernel and user level threads z
Multithreading models (next slides)
Operating System Concepts – 7th edition, Jan 23, 2005
4.19
Silberschatz, Galvin and Gagne ©2005
Thread Libraries A thread library provides the programmer with an API for creating
and managing threads. Implemented either in the user space (function call) or the kernel
space (system call) Three primary thread libraries: z
POSIX Pthreads. May
z
be either a user- or kernel-level library.
Win32 threads. Kernel-level
z
library.
Java threads Typically
implemented using a thread library available on the JVM’s host system.
Operating System Concepts – 7th edition, Jan 23, 2005
4.20
Silberschatz, Galvin and Gagne ©2005
10
Pthreads A POSIX standard (IEEE 1003.1c) API for thread creation and
synchronization. The Pthreads API standard is a specification for thread behavior.
Implementation is left up to the developer of the library. Common in UNIX operating systems (Solaris, Linux, Mac OS X,
Tru64 Unix). z
Sharewares available for the Windows OS
Very useful example of Pthreads usage is explained in page 133
Operating System Concepts – 7th edition, Jan 23, 2005
4.21
Silberschatz, Galvin and Gagne ©2005
Multithreading Models Specifies the relationship between user threads and kernel threads. Use kernel-level threads and then multiplex user-level threads
onto some or all of the kernel threads. The kernel is aware of only the kernel-level threads and schedules
those. Three models of doing so: z
Many-to-One
z
One-to-One
z
Many-to-Many
Operating System Concepts – 7th edition, Jan 23, 2005
4.22
Silberschatz, Galvin and Gagne ©2005
11
Many-to-One Many user-level threads mapped to single kernel thread z
On older Unix, only one “kernel thread” per process
z
Thread management done by the thread library routines at user level.
z
Entire process will block if a thread makes a blocking system call.
z
Multiple threads unable to run in parallel on multiprocessors since only one thread can access the kernel at a time.
z
May be used on systems that do not support kernel threads.
Examples: z
Solaris Green Threads
z
GNU Portable Threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.23
Silberschatz, Galvin and Gagne ©2005
Many-to-One Model
Operating System Concepts – 7th edition, Jan 23, 2005
4.24
Silberschatz, Galvin and Gagne ©2005
12
One-to-One Each user-level thread maps to a kernel-level thread z
Provides more concurrency than many-to-one (or many-tomany) by allowing another thread to run during blocking system calls.
z
Multiple threads can run in parallel on multiprocessors.
z
Most implementations restrict the number of kernel threads supported by the system due to overhead ( since creating a user thread requires creating the corresponding kernel thread, which can affect the system performance. Thus, the number is limited)
Examples z
Windows NT/XP/2000
z
Linux
z
Solaris 9 and later
Operating System Concepts – 7th edition, Jan 23, 2005
4.25
Silberschatz, Galvin and Gagne ©2005
One-to-one Model
Operating System Concepts – 7th edition, Jan 23, 2005
4.26
Silberschatz, Galvin and Gagne ©2005
13
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 to server the user threads. z
Does not suffer from the blocking of all threads during a blocking system call, and the user threads are not limited by the number of kernel threads
Solaris prior to version 9 Windows NT/2000 with the ThreadFiber package
Operating System Concepts – 7th edition, Jan 23, 2005
4.27
Silberschatz, Galvin and Gagne ©2005
Many-to-Many Model
Operating System Concepts – 7th edition, Jan 23, 2005
4.28
Silberschatz, Galvin and Gagne ©2005
14
Multithreading Models
Operating System Concepts – 7th edition, Jan 23, 2005
4.29
Silberschatz, Galvin and Gagne ©2005
Two-level Model Similar to M:M, except that it allows a user thread to be
bound directly to a kernel thread Examples z
IRIX
z
HP-UX
z
Tru64 UNIX
z
Solaris 8 and earlier
Operating System Concepts – 7th edition, Jan 23, 2005
4.30
Silberschatz, Galvin and Gagne ©2005
15
Two-level Model
Operating System Concepts – 7th edition, Jan 23, 2005
4.31
Silberschatz, Galvin and Gagne ©2005
Implementing Threads Implementing threads has a number of issues z
Interface (thread libraries)
z
Context switch
z
Preemptive vs. non-preemptive
z
Scheduling
z
Synchronization
Focus on user-level threads z
Kernel-level threads are similar to original process management and implementation in the OS
Operating System Concepts – 7th edition, Jan 23, 2005
4.32
Silberschatz, Galvin and Gagne ©2005
16
Threading Issues Semantics of fork() and exec() system calls Thread cancellation Signal handling Thread pools Thread specific data Scheduler activations
Operating System Concepts – 7th edition, Jan 23, 2005
4.33
Silberschatz, Galvin and Gagne ©2005
Semantics of fork() and exec() Does fork() create a new process which duplicates only the calling
thread, or all threads? z
May have two versions of fork(). One that duplicates all threads and another that duplicates only the thread that invoked the fork() system call
z
Which one to use? Depends on the application if it call exec() directly after fork or not.
If a thread invokes exec(), the new program replaces the entire
process, including all threads.
Operating System Concepts – 7th edition, Jan 23, 2005
4.34
Silberschatz, Galvin and Gagne ©2005
17
Thread Cancellation Terminating a thread before it has finished z
Press stop button before a browser load all images.
Two general approaches: z
Asynchronous cancellation terminates the thread to be cancelled (target thread) immediately
z
Deferred cancellation allows the target thread to periodically check if it should be cancelled, allowing it an opportunity to terminate itself in an orderly fashion
Difficult in situations where recourses have been allocated
to the target thread or when a thread is cancelled while in the middle of updating date it is sharing with other threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.35
Silberschatz, Galvin and Gagne ©2005
Signal Handling
Signals (synchronous, asynchronous) 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 the signal handler (default or userdefined)
Options for delivering a signal z
Deliver the signal to the thread to which the signal applies
z
Deliver the signal to every thread in the process
z
Deliver the signal to certain threads in the process
z
Assign a specific thread to receive all signals for the process
Threads can specify which signals to receive.
Operating System Concepts – 7th edition, Jan 23, 2005
4.36
Silberschatz, Galvin and Gagne ©2005
18
Thread Pools At process startup, create a number of threads and put them
in a pool, where they await work Advantages: z
Usually slightly faster to service a request with an existing thread than create a new thread
z
Allows the number of threads in the application(s) to be bound to the size of the pool. Important on systems that cannot support a large number of concurrent threads.
Operating System Concepts – 7th edition, Jan 23, 2005
4.37
Silberschatz, Galvin and Gagne ©2005
Thread Specific Data 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)
Operating System Concepts – 7th edition, Jan 23, 2005
4.38
Silberschatz, Galvin and Gagne ©2005
19
Scheduler Activations Both M:M and Two-level models require communication to
maintain the appropriate number of kernel threads allocated to the application lightweight process is an intermediate data structure
between the user and kernel threads, which appears as a virtual process to the user-thread library.. Scheduler activations provide upcalls - a communication
mechanism from the kernel to the thread library Allows the kernel library to schedule (LWPs) across the
virtual processors provided by the kernel threads. This communication allows an application to maintain the
correct number kernel threads
Operating System Concepts – 7th edition, Jan 23, 2005
4.39
Silberschatz, Galvin and Gagne ©2005
Thread Scheduling The thread scheduler determines when a thread runs It uses queues to keep track of what threads are doing z
Just like the OS and processes
z
But it is implemented at user-level in a library
Run queue: Threads currently running (usually one) Ready queue: Threads ready to run Scheduling more than one thread means that we need to switch
between threads z
In other words, it context switches to another thread
Operating System Concepts – 7th edition, Jan 23, 2005
4.40
Silberschatz, Galvin and Gagne ©2005
20
Thread Context Switch The context switch routine does all of the magic z
Saves context of the currently running thread (old_thread) Push
all machine state onto its stack (not its TCB)
z
Restores context of the next thread
z
The next thread becomes the current thread
z
Return to caller as new thread
Pop
all machine state from the next thread’s stack
This is all done in assembly language
Operating System Concepts – 7th edition, Jan 23, 2005
4.41
Silberschatz, Galvin and Gagne ©2005
Windows XP Threads Implements the one-to-one mapping Each thread contains z
A thread id
z
Register set
z
Separate user and kernel stacks
z
Private data storage area
The register set, stacks, and private storage area are known
as the context of the threads The primary data structures of a thread include: z
ETHREAD (executive thread block)
z
KTHREAD (kernel thread block)
z
TEB (thread environment block)
Operating System Concepts – 7th edition, Jan 23, 2005
4.42
Silberschatz, Galvin and Gagne ©2005
21
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)
Operating System Concepts – 7th edition, Jan 23, 2005
4.43
Silberschatz, Galvin and Gagne ©2005
Threads Summary The operating system as a large multithreaded program z
Each process executes as a thread within the OS
Multithreading is also very useful for applications z
Efficient multithreading requires fast primitives
z
Processes are too heavyweight
Solution is to separate threads from processes z
Kernel-level threads much better, but still significant overhead
z
User-level threads even better, but not well integrated with OS
Now, how do we get our threads to correctly cooperate with each
other? z
Synchronization…
Operating System Concepts – 7th edition, Jan 23, 2005
4.44
Silberschatz, Galvin and Gagne ©2005
22
End of Chapter 4
23
