Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 221 times |
Download: | 0 times |
ThreadsCS-502 Fall 2006 1
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)
ThreadsCS-502 Fall 2006 2
Processes – Review
• Fundamental abstraction in all operating systems
• Implementation and management of concurrent activity
• Also known as task, job, thread of control, etc.
ThreadsCS-502 Fall 2006 3
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.)
ThreadsCS-502 Fall 2006 4
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
ThreadsCS-502 Fall 2006 5
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.
ThreadsCS-502 Fall 2006 7
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
ThreadsCS-502 Fall 2006 8
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
ThreadsCS-502 Fall 2006 9
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
ThreadsCS-502 Fall 2006 10
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
ThreadsCS-502 Fall 2006 11
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)
ThreadsCS-502 Fall 2006 12
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
ThreadsCS-502 Fall 2006 13
Threads
0x00000000
0xFFFFFFFF
Virtual
address space
code(text)
static data
heap
thread 1 stack
PC (T2)
SP (T2)thread 2 stack
thread 3 stack
SP (T1)
SP (T3)
PC (T1)
PC (T3)
SP
PC
ThreadsCS-502 Fall 2006 15
Benefits
• Responsiveness
• Resource Sharing
• Economy
• Utilization of multi-processor architectures
ThreadsCS-502 Fall 2006 16
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()
ThreadsCS-502 Fall 2006 17
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
ThreadsCS-502 Fall 2006 18
User Threads
• Thread management done by user-level threads library
• Three primary thread libraries:– POSIX Pthreads– Win32 threads– Java threads
ThreadsCS-502 Fall 2006 19
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
ThreadsCS-502 Fall 2006 20
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!
ThreadsCS-502 Fall 2006 21
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
ThreadsCS-502 Fall 2006 22
Kernel Threads
• Supported by the Kernel• OS maintains data structures for thread state and
does all of the work of thread implementation.
• Examples• Windows XP/2000
• Solaris
• Linux
• Tru64 UNIX
• Mac OS X
ThreadsCS-502 Fall 2006 23
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
ThreadsCS-502 Fall 2006 24
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
ThreadsCS-502 Fall 2006 25
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
ThreadsCS-502 Fall 2006 27
Many-to-One
• Many user-level threads mapped to single kernel thread
• Examples:• Solaris Green Threads
• GNU Portable Threads
ThreadsCS-502 Fall 2006 29
One-to-One
• Each user-level thread maps to kernel thread
• Examples• Windows NT/XP/2000
• Linux
• Solaris 9 and later
ThreadsCS-502 Fall 2006 31
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
ThreadsCS-502 Fall 2006 33
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
ThreadsCS-502 Fall 2006 35
Threading Issues
• Semantics of fork() and exec() system calls for processes
• Thread cancellation
• Signal handling
• Thread pools
• Thread specific data
• Scheduler activations
ThreadsCS-502 Fall 2006 36
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
ThreadsCS-502 Fall 2006 37
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
ThreadsCS-502 Fall 2006 38
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 signals1. Signal is generated by particular event2. Signal is delivered to a process3. 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
ThreadsCS-502 Fall 2006 39
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
ThreadsCS-502 Fall 2006 40
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)
ThreadsCS-502 Fall 2006 41
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
ThreadsCS-502 Fall 2006 42
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;
};
ThreadsCS-502 Fall 2006 43
Threads inside the OS kernel
• Kernels have evolved into large, multi-threaded 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
ThreadsCS-502 Fall 2006 44
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