ThreadsCS-502 Fall 20061 Threads CS-502 Operating Systems (Slides include materials from Operating System Concepts, 7 th ed., by Silbershatz, Galvin, &

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)


Processes – Review

• Fundamental abstraction in all operating systems

• Implementation and management of concurrent activity

• Also known as task, job, thread of control, etc.


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.)



• 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



• 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.


Questions?


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


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


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


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


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)


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


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


Single and Multithreaded Processes


Benefits

• Responsiveness

• Resource Sharing

• Economy

• Utilization of multi-processor architectures


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()


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


User Threads

• Thread management done by user-level threads library

• Three primary thread libraries:– POSIX Pthreads– Win32 threads– Java threads


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


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!


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


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


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


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

http://www.intel.com/products/ht/hyperthreading_more.htm


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


Models for Implementation

• Many-to-One

• One-to-One

• Many-to-Many


Many-to-One

• Many user-level threads mapped to single kernel thread

• Examples:• Solaris Green Threads

• GNU Portable Threads


Many-to-One Model


One-to-One

• Each user-level thread maps to kernel thread

• Examples• Windows NT/XP/2000

• Linux

• Solaris 9 and later


One-to-one Model


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


Many-to-Many Model


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


Two-level Model


Threading Issues

• Semantics of fork() and exec() system calls for processes

• Thread cancellation

• Signal handling

• Thread pools

• Thread specific data

• Scheduler activations


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


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


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


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


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)


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


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;

};


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


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


Break

Next topic

Documents

ThreadsCS-502 Fall 20061 Threads CS-502 Operating Systems (Slides include materials from Operating System Concepts, 7 th ed., by Silbershatz, Galvin, &