- Support for threads may be provided either at the user level, for user threads, or by the kernel, for kernel threads.
- User threads are supported above the kernel and are managed without kernel support,
- whereas kernel threads are supported and managed directly by the OS.
(a) A user-level threads package. (b) A threads package managed by the kernel.
- Implementing Threads in User Space:
- The threads package entirely in user space (see Fig. 4.4a). The kernel knows nothing about them.
- The first, and most obvious, advantage is that a user-level threads package can be implemented on an OS that does not support threads.
- Among other issues, no trap is needed, no context switch is needed, the memory cache need not be flushed, and so on. This makes thread scheduling very fast.
- Despite their better performance, user-level threads packages have a major problem as if a thread starts running, no other thread in that process will ever run unless the first thread voluntarily gives up the CPU.
- While user threads usually have lower management load compared to kernel threads, one must consider this in relation to their lower functionality.
- Implementing Threads in the Kernel:
- Supported by the kernel, the kernel performs all management (creation, scheduling, deletion, etc., see Fig. 4.4b).
- There is no thread table in each process. Instead, the kernel has a thread table that keeps track of all the threads in the system.
- if one thread blocks, another may be run. In addition, if one thread in a process causes a page fault, the kernel can easily check to see if the process has any other runnable threads.
- Ultimately, there must exist a relationship between user threads and kernel threads.