Day 12 Threads

Exam 1 on Wednesday morning at 8:30 AM C, Linux, Makefiles,svn, Chapters 1,2, and 3 Open book, open notes, limited computer usage

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.

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

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 secondary threads complete. The primary thread is said to JOIN each of the thread it creates. When a thread A joins B, A does not execute until B 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 i.e. m:1) Many threads mapped onto one process 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 Allows the user to use scheduling algorithms that are more appropriate to the application. Application must allocate stack for each thread Uses a thread table (similar to a process table) The kernel is unaware of threads 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). Examples: POSIX Pthreads, Mach C-threads, Solaris ui-threads

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.

Kernel-level threads (KLT) (One to one mapping i.e. 1:1) 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 (m) and these can be mapped to smaller number(n) 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, 5th edition) Deitel, Deitel and Choffnes, “Operating Systems,” 3rd edition, Prentice Hall.