Multithreading Models

• 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.

  Figure 4: (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. 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. 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.