CS 703 Advanced Operating Systems By Mr Farhan

CS 703 – Advanced Operating Systems By Mr. Farhan Zaidi

Lecture No. 7

Overview of today’s lecture n n n The design space for threads Threads illustrated and view in an address space User level and kernel level thread implementations Problems and advantages of user level thread implementations Problems and advantages of kernel level thread implementations Re-cap of lecture

The design space Key older UNIXes MS/DOS one thread/process one process address space thread one thread/process many processes Java many threads/process one process many threads/process many processes Mach, NT, Chorus, Linux, …

(old) Process address space 0 x. FFFF stack (dynamic allocated mem) SP address space heap (dynamic allocated mem) static data (data segment) 0 x 0000 code (text segment) PC

(new) Process address space with thread 1 stack threads SP (T 1) 0 x. FFFF thread 2 stack SP (T 2) thread 3 stack SP (T 3) address space heap (dynamic allocated mem) static data (data segment) 0 x 0000 code (text segment) PC (T 2) PC (T 1) PC (T 3)

Process/thread separation n Concurrency (multithreading) is useful for: q q q n Multithreading is useful even on a uniprocessor q n handling concurrent events (e. g. , web servers and clients) building parallel programs (e. g. , matrix multiply, ray tracing) improving program structure (the Java argument) even though only one thread can run at a time Supporting multithreading – that is, separating the concept of a process (address space, files, etc. ) from that of a minimal thread of control (execution state), is a big win q q creating concurrency does not require creating new processes “faster / better / cheaper”

Kernel threads n OS manages threads and processes q q n Kernel threads are cheaper than processes q n all thread operations are implemented in the kernel OS schedules all of the threads in a system n if one thread in a process blocks (e. g. , on I/O), the OS knows about it, and can run other threads from that process n possible to overlap I/O and computation inside a process less state to allocate and initialize But, they’re still pretty expensive for fine-grained use (e. g. , orders of magnitude more expensive than a procedure call) q q thread operations are all system calls n context switch n argument checks must maintain kernel state for each thread

User-level threads n To make threads cheap and fast, they need to be implemented at the user level q managed entirely by user-level library, e. g. , libpthreads. a n User-level threads are small and fast q each thread is represented simply by a PC, registers, a stack, and a small thread control block (TCB) q q creating a thread, switching between threads, and synchronizing threads are done via procedure calls n no kernel involvement is necessary! user-level thread operations can be 10 -100 x faster than kernel threads as a result

User-level thread implementation n n The kernel believes the user-level process is just a normal process running code q But, this code includes the thread support library and its associated thread scheduler The thread scheduler determines when a thread runs q it uses queues to keep track of what threads are doing: run, ready, wait n n just like the OS and processes but, implemented at user-level as a library

Kernel threads Mach, NT, Chorus, Linux, … address space os kernel thread CPU (thread create, destroy, signal, wait, etc. )

User-level threads, conceptually user-level thread library address space ? os kernel thread CPU Mach, NT, Chorus, Linux, … (thread create, destroy, signal, wait, etc. )

Multiple kernel threads “powering” each address space user-level thread library Mach, NT, Chorus, Linux, … address space os kernel thread CPU (kernel thread create, destroy, signal, wait, etc. ) (thread create, destroy, signal, wait, etc. ) kernel threads

How to keep a user-level thread from hogging the CPU? n Strategy 1: force everyone to cooperate q q q n a thread willingly gives up the CPU by calling yield() calls into the scheduler, which context switches to another ready thread what happens if a thread never calls yield()? Strategy 2: use preemption q q scheduler requests that a timer interrupt be delivered by the OS periodically n usually delivered as a UNIX signal (man signal) n signals are just like software interrupts, but delivered to user-level by the OS instead of delivered to OS by hardware at each timer interrupt, scheduler gains control and context switches as appropriate

Thread context switch n Very simple for user-level threads: q q q n save context of currently running thread n push machine state onto thread stack restore context of the next thread n pop machine state from next thread’s stack return as the new thread n execution resumes at PC of next thread This is all done by assembly language q it works at the level of the procedure calling convention n thus, it cannot be implemented using procedure calls n e. g. , a thread might be preempted (and then resumed) in the middle of a procedure call n C commands setjmp and longjmp are one way of doing it

What if a thread tries to do I/O? n n n The kernel thread “powering” it is lost for the duration of the (synchronous) I/O operation! Could have one kernel thread “powering” each user-level thread q no real difference from kernel threads – “common case” operations (e. g. , synchronization) would be quick Could have a limited-size “pool” of kernel threads “powering” all the user-level threads in the address space q the kernel will be scheduling these threads, obliviously to what’s going on at user-level

What if the kernel preempts a thread holding a lock? n Other threads will be unable to enter the critical section and will block (stall) q n tradeoff, as with everything else Solving this requires coordination between the kernel and the user-level thread manager q “scheduler activations” n each process can request one or more kernel threads q process is given responsibility for mapping user-level threads onto kernel threads q kernel promises to notify user-level before it suspends or destroys a kernel thread

Pros and Cons of User Level threads Pros n n Procedure invocation instead of system calls results in fast scheduling and thus much better performance Could run on exisiting OSes that don’t support threads Customized scheduling. Useful in many cases e. g. in case of garbage collection Kernel space not required for thread specific data. Scale better for large number of threads

Pros and Cons of User Level threads Cons n n n Blocking system calls affect all threads Solution 1: Make the system calls non-blocking. Is this a good solution? Solution 2: Write Jacket or wrapper routines with select. What about this solution? Requires re-writing parts of system call library. Similar problem occurs with page faults. The whole process blocks Voluntary yield to the run-time system necessary for context switch Solution: Run time system may request a clock signal.

Pros and Cons of User Level threads n Programs that use multi-threading need to make system calls quite often. If they don’t then there is usually no need to be multi-threaded.

Pros and cons of kernel level threads n n Blocking system calls cause no problem Page faults can be handled by scheduling another thread from the same process (if one is ready) Cost of system call substantially greater Solution: thread recycling; don’t destroy thread data structures when the thread is destroyed.