Threads

Processes and Threads  Two characteristics of “processes” as considered so far: Unit of resource allocation Unit of dispatch  Characteristics are separable Processes (or tasks) are allocated resources Threads (or lightweight processes) are dispatched

What is a thread?  A set of threads have shared access to the resources of a process (including memory)  Each thread has its own thread control block (TCB). Since each thread has its own TCB, it also has its own PC, GP registers, and state.  Each thread also has its own kernel stack, user stack, and space for static variables  A thread is a unit of dispatching within a 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.  One process many threads – Java runtime environment.

Why threads?  Less time to create a thread  Less time to delete a thread  Switching between threads of the same process is faster  Communication between threads within a single process is more efficient than communication between processes  On shared-memory multi-processor systems, threads can be scheduled on different processors

Thread examples  Web server  Word processor  Others?

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

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. 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.  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 result in a much faster execution time than KLTs which are much faster than processes.