Download Threads (and more on Processes)

Threads
CS-502 Operating Systems
(Slides include materials from Operating System Concepts, 7th ed., by Silbershatz, Galvin,
& Gagne and from Modern Operating Systems, 2nd ed., by Tanenbaum)
CS-502 Fall 2006
Threads
1
Processes – Review
• Fundamental abstraction in all operating
systems
• Implementation and management of
concurrent activity
• Also known as task, job, thread of control,
etc.
CS-502 Fall 2006
Threads
2
Processes – Review (continued)
• Process state –information maintained by
OS for representing process, in PCB
• PSW, registers, condition codes, etc.
• Memory, files, resources, etc.
• Priority, blocking status, etc.
• Queues
• Ready Queue
• Semaphore queues
• Other kinds of queues not yet covered (e.g., for
disks, communication resources, etc.)
CS-502 Fall 2006
Threads
3
Processes – Review (continued)
• Interrupts and traps
• Switching contexts
• Saving state of one process
• Loading state of another process
• Scheduling
• Deciding which process to run (or serve) next
• More later this evening
• Interprocess Communication
• Later in the course
CS-502 Fall 2006
Threads
4
Processes – Review (continued)
• Process creation
• Fork + Exec (Unix-Linux)
• Create Process (Windows)
• Relationships among processes
• Parent-child (Unix-Linux)
• No default relationship (Windows)
• Process termination
• Wait for child processes, etc.
CS-502 Fall 2006
Threads
5
Questions?
CS-502 Fall 2006
Threads
6
Problem –
Unix/Windows Processes are “heavyweight”
• Lots of data in process context
• Even more when we study memory management
• More than that when we study file systems, etc.
• Processor caches a lot of information
• Memory Management information
• Caches of active pages
• Costly context switches and traps
• 100’s of microseconds
CS-502 Fall 2006
Threads
7
Problem – Heavyweight Unix/Windows
Processes (continued)
• Separate processes have separate address
spaces
• Shared memory is limited or nonexistent
• Applications with internal concurrency are difficult
• Isolation between independent processes vs.
cooperating activities
• Fundamentally different goals
CS-502 Fall 2006
Threads
8
Example
• Web Server – How to support multiple concurrent
requests
• One solution:
– create several processes that execute in parallel
– Use shared memory (shmget()) to map to the same
address space in the processes
– have the OS schedule them in parallel
• Not efficient
– space: PCB, page tables, etc.
– time: creating OS structures (fork()) and context
switch
CS-502 Fall 2006
Threads
9
Example 2
• Transaction processing systems
• E.g, airline reservations or bank ATM transactions
• 1000’s of transactions per second
• Very small computation per transaction
• Separate processes per transaction are too
costly
• Other techniques (e.g., message passing) are
much more complex
CS-502 Fall 2006
Threads
10
This problem …
• … is partly an artifact of
• Unix, Linux, and Windows
and of
• Big, powerful processors (e.g., Pentium 4)
• … tends to occur in most large systems
• … is infrequent in small-scale systems
• PDAs, cell phones, hand-held games
• Closed systems (i.e., controlled applications)
CS-502 Fall 2006
Threads
11
Solution:– Threads
• A thread is the execution of a program or
procedure within the context of a Unix or
Windows process
• I.e., a specialization of the concept of process
• A thread has its own
• Program counter, registers, PSW
• Stack
• A thread shares
• Address space, heap, static data
• All other resources
with all other threads of the same process
CS-502 Fall 2006
Threads
12
Threads
thread 1 stack
SP (T1)
0xFFFFFFFF
thread 2 stack
SP
SP (T2)
thread 3 stack
SP (T3)
Virtual
address space
heap
static data
0x00000000
CS-502 Fall 2006
PC
PC (T2)
PC (T1)
PC (T3)
code
(text)
Threads
13
Single and Multithreaded Processes
CS-502 Fall 2006
Threads
14
Benefits
• Responsiveness
• Resource Sharing
• Economy
• Utilization of multi-processor architectures
CS-502 Fall 2006
Threads
15
Threads
• Linux, Windows, and various versions of
Unix have their own thread interfaces
• Similar, not standardized
• Some issues
• E.g., ERRNO in Unix — a static variable set by
system calls
• Semantics of fork() and exec()
CS-502 Fall 2006
Threads
16
Who creates and manages threads?
• User-level implementation
– done with function library (e.g., POSIX)
– Runtime system – similar to process
management except in user space
– Windows NT – fibers: a user-level thread
mechanism
• Kernel implementation – new system calls
and new entity to manage
– Linux: lightweight process (LWP)
– Windows NT & XP: threads
CS-502 Fall 2006
Threads
17
User Threads
• Thread management done by user-level
threads library
• Three primary thread libraries:
– POSIX Pthreads
– Win32 threads
– Java threads
CS-502 Fall 2006
Threads
18
User Threads (continued)
• Can be implemented without kernel support
• … or knowledge!
• Program links with a runtime system that does
thread management
• Operation are very efficient (procedure calls)
• Space efficient and all in user space (TCB)
• Task switching is very fast
• Since kernel not aware of threads, there can be
scheduling inefficiencies
• E.g., blocking I/O calls
• Non-concurrency of threads on multiple processors
CS-502 Fall 2006
Threads
19
User Threads (continued)
• Thread Dispatcher
– Queues in process memory to keep track of threads’ state
• Scheduler – non-preemptive
– Assume threads are well-behaved
– Thread voluntarily gives up CPU by calling yield() – does thread
context switch to another thread
• Scheduler – preemptive
–
–
–
–
Assumes threads may not be well-behaved
Scheduler sets timer to create a signal that invokes scheduler
Scheduler can force thread context switch
Increased overhead
• Application or thread library must handle all concurrency
itself!
CS-502 Fall 2006
Threads
20
Thread Interface
• E.g., POSIX pthreads API:
– int pthread_create(pthread_t *thread, const
pthread_attr_t *attr, void*(*start_routine) (void), void
*arg)
• creates a new thread of control
• new thread begins executing at start_routine
– pthread_exit(void *value_ptr)
• terminates the calling thread
– pthread_join(pthread_t thread, void **value_ptr)
• blocks the calling thread until the thread specified terminates
– pthread_t pthread_self()
• Returns the calling thread's identifier
CS-502 Fall 2006
Threads
21
Kernel Threads
• Supported by the Kernel
• OS maintains data structures for thread state and
does all of the work of thread implementation.
• Examples
•
•
•
•
•
CS-502 Fall 2006
Windows XP/2000
Solaris
Linux
Tru64 UNIX
Mac OS X
Threads
22
Kernel Threads (continued)
• OS schedules threads instead of processes
• Benefits
– Overlap I/O and computing in a process
– Creation is cheaper than processes
– Context switch can be faster than processes
• Negatives
– System calls (high overhead) for operations
– Additional OS data space for each thread
CS-502 Fall 2006
Threads
23
Threads – supported by processor
• E.g., Pentium 4 with Hyperthreading™
• www.intel.com/products/ht/hyperthreading_more.htm
• Multiple CPU’s on a single chip
• True concurrent execution within a single process
• Requires kernel support
• Re-opens old issues
• Deadlock detection
• Critical section management of synchronization primitives
CS-502 Fall 2006
Threads
24
Unix Processes vs. Threads
• On a 700 Mhz Pentium running Linux
– Processes:
• fork()/exit() : 250 microsec
– Kernel threads:
• pthread_create()/pthread_join(): 90 microsec
– User-level threads:
• pthread_create()/pthread_join(): 5 microsec
CS-502 Fall 2006
Threads
25
Models for Implementation
• Many-to-One
• One-to-One
• Many-to-Many
CS-502 Fall 2006
Threads
26
Many-to-One
• Many user-level threads mapped to single
kernel thread
• Examples:
• Solaris Green Threads
• GNU Portable Threads
CS-502 Fall 2006
Threads
27
Many-to-One Model
CS-502 Fall 2006
Threads
28
One-to-One
• Each user-level thread maps to kernel thread
• Examples
• Windows NT/XP/2000
• Linux
• Solaris 9 and later
CS-502 Fall 2006
Threads
29
One-to-one Model
CS-502 Fall 2006
Threads
30
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 NT/2000 with the ThreadFiber
package
CS-502 Fall 2006
Threads
31
Many-to-Many Model
CS-502 Fall 2006
Threads
32
Two-level Model
• Similar to M:M, except that it allows a user
thread to be bound to kernel thread
• Examples
•
•
•
•
CS-502 Fall 2006
IRIX
HP-UX
Tru64 UNIX
Solaris 8 and earlier
Threads
33
Two-level Model
CS-502 Fall 2006
Threads
34
Threading Issues
• Semantics of fork() and exec() system calls
for processes
• Thread cancellation
• Signal handling
• Thread pools
• Thread specific data
• Scheduler activations
CS-502 Fall 2006
Threads
35
Semantics of fork() and exec()
• Does fork() duplicate only the calling
thread or all threads?
– Easy if user-level threads
– Not so easy with kernel-level threads
• Linux has special clone() operation
• Windows XP has something similar
CS-502 Fall 2006
Threads
36
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
CS-502 Fall 2006
Threads
37
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 thread to receive all signals for the
process
CS-502 Fall 2006
Threads
38
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
CS-502 Fall 2006
Threads
39
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)
CS-502 Fall 2006
Threads
40
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
CS-502 Fall 2006
Threads
41
Mutual Exclusion within Threads
extern void thread_yield();
extern int TestAndSet(int &i);
/* sets the value of i to 1 and returns the
previous value of i. */
void enter_critical_region(int &lock) {
while (TestAndSet(lock) == 1)
thread_yield(); /* give up processor */
};
void leave_critical_region(int &lock) {
lock = 0;
};
CS-502 Fall 2006
Threads
42
Threads inside the OS kernel
• Kernels have evolved into large, multithreaded programs.
• Lots of concurrent activity
• Multiple devices operating at one time
• Multiple application activities at one time
• A useful tool
• Special kernel thread packages, synchronization
primitives, etc.
• Useful for complex OS environments
CS-502 Fall 2006
Threads
43
Threads – Summary
• Processes are very heavyweight in Unix,
Linux, Windows, etc.
• Need for isolation between processes at odds with
desire for concurrency within processes
• Threads provide an efficient alternative
Thread implementation and management
strategies depend upon expected usage
• Kernel support or not
• Processor support or not
CS-502 Fall 2006
Threads
44
Break
Next topic
CS-502 Fall 2006
Threads
45