Day 10 Threads

Threads and Processes  Process is seen as two entities Unit of resource allocation (process or task) Unit of dispatch or scheduling (thread or lightweight process)

What is a thread?  A thread is a unit of dispatching within a process.  A thread has a kernel stack, user stack and a TCB. The TCB implies that it has its own copy of the PC, GP registers and state i.e. running, not running. It also has a per thread static storage for local variables.  A thread has access to memory and resources of its process shared by all threads in the process.

Threads in modern operating systems  Single-threading - Only 1 process(DOS) or 1 thread per process (flavors of UNIX).  Multi-threading - More than 1 thread in 1 process and many processes - Solaris, W2K, LINUX.

Why threads?  Less time to create a thread.  Less time to delete a thread.  Switching between threads of the same process is faster as user address space need not be restored.  Communication is more efficient as they share the address space and don't need to invoke the kernel for message passing.  On multi-processor systems, threads can be scheduled on different processors and increase efficiency.  All resources of the process are available to the child thread. e.g. same file pointer

Thread examples  Web server  Word processor

Figure 4.2 Thread life cycle. [Deitel et al] 4.4 Thread States: Life Cycle of a Thread

Common Thread operations  create, exit  join - When a process is created a primary thread is created. If the primary thread returns, the process terminates. In order to make the process wait for secondary threads to finish, the primary thread is put to sleep until the secondary thread completes. The primary thread is said to JOIN each of the thread it creates.  When a thread T1 joins T2, T1 does not execute until T2 terminates.

POSIX threads  Portable Operating Systems Interface for Computing Environments. – Is an IEEE standard.  provides a standard interface between threads and the library.  Not concerned with the details of the implementation – can be implemented at the OS level or at the application level.  Functions: Sleep(seconds) – puts the entire process to sleep.  Use pthread_delay_np to make thread sleep. exit() – causes the entire process to quit.  Use pthread_exit to make thread quit. pthread_self() – id of the current thread pthread_setsched_parama() – to voluntarily yield the scheduler  Solaris threads are defined in thread.h while pthreads are defined in pthread.h  Use “-lpthread” to compile programs that includes functions from the pthread library.

User level threads and kernel level threads

User level threads (Many to one mapping)  Implement thread creation/manipulation using procedure calls to a user-level library rather than system calls. ULTs can run on any OS, as long as the thread library is available.  The thread management is done by the application and the kernel is unaware of threads. Allows the user to use scheduling algorithms that are more appropriate to the application.  Switching between threads is done without invoking the kernel and the only context that needs to be saved is the program counter, user registers and stack pointers.(Threads voluntarily give up the CPU).

User level threads (Many to one mapping)  OS is unaware of the threads and schedules independent of number of threads per process. A process with many threads is not going to be assigned a larger time- slice to run than a process with fewer threads  If the application does require system calls, then when a thread gets blocked, process itself gets blocked.  In a multi-processing environment, the kernel cannot schedule different threads of a process on different processors as it is unaware of the threads.

Kernel-level threads (KLT) (One to one mapping)  OS is aware of all the threads. Switch between threads requires a mode switch - still inexpensive as the context is still small - more expensive than ULT as mode switch required.  OS schedules the threads and hence if a thread blocks a process need not block.  Can be efficiently used in a multi-processing environment.

Kernel-level threads (KLT) (One to one mapping)  Less portable as the code has to be re-written to use the API of the under-lying OS. Use of POSIX threads reduces this problem.  A lot of overhead on the OS as a process may have 100s of threads and this would result in thousands of dispatch units for the OS to manage.  Linux supports the one-to-one i.e. KLT model. Efficient mode(context) switching mechanism is available.

Combined approach (many to many or m-to-n approach)  Windows XP and old versions of Solaris  A process may have a number of ULTs and these can be mapped to smaller number or equal number of KLTs.  By allowing the mapping, we can reduce the number of threads the OS sees. The programmer can select which threads (blocking threads) are seen by the kernel separate from the non-blocking.  Creation, synchronization etc. are done at the application level.

If one were to generalize,  It could be said that ULTs results in a much faster execution time than KLTS which are much faster than processes.  Also, use ULTs for CPU-bound operations i.e. not requiring too many system calls. Use KLTs for I/O bound processes and in cases where multi-processing can be taken advantage of.

Support for threads  A number of languages now support multi-threading. Initially, it was only Ada. But, Ada was used primarily in military applications. Java, C#, Python, Visual C++.NET and Visual BASIC.NET all currently support multi- threading. C and C++ traditionally did not. But, now include special libraries.  Most OS support multi-threading. Win-32 threads, C-thread(Mach) and POSIX threads, Solaris threads. POSIX specifies the Pthread standard. Allows portable code and is supported by Solaris, LINUX and Windows XP.

References  Listed textbook (Stallings, 6 th edition)  Deitel, Deitel and Choffnes, “Operating Systems,” 3 rd edition, Prentice Hall.