Who manages threads?

Two strategies

• User threads

  • Thread management done by user level thread library.

  • Kernel knows nothing about the threads.

• Kernel threads

  • Threads directly supported by the kernel.
  • Known as light weight processes.

User level threads

• All thread management is done by the application

• The kernel is not aware of the existence of threads

Advantages:

• Fast (really lightweight) (no system call to manage threads. The thread library does everything).
• Can be implemented in an OS that does not support threading.
• Switching is fast. No switch from user to protected mode.

Disadvantages:

• Scheduling can be an issue. (Consider, one thread that is blocked on an IO and another runnable.)
• Lack of coordination between kernel and threads. (A process with 100 threads competes for a timeslice with a process having just 1 thread.)
• Requires non-blocking system calls. (If one thread invokes a system call, all threads need to wait)

Kernel level threads

• Thread management is done by the kernel
• There is no thread management code in the application level, simply an application programming interface (API) to the kernel thread facility
• Windows is an example of this approach

Advantages:

• Scheduler can decide to give more time to a process having large number of threads than process having small number of threads.
• Kernel-level threads are especially good for applications that frequently block.

Disadvantages:

• The kernel-level threads are slow (they involve kernel invocations.) Overheads in the kernel. (Since kernel must manage and schedule threads as well as processes. It require a full thread control block (TCB) for each thread to maintain information about threads.)