Q. Multithreading is a commonly utilized programming technique. Illustrate three different ways that threads could be implemented. Describe how these ways compare to the Linux clone mechanism. When might every alternative mechanism be better or worse than using clones?

Answer: Thread implementations can be largely classified into two groups- kernel-based threads as well as user-mode threads. User-mode thread packages rely on some kernel support-they may require timer interrupt facilities for instance-but the scheduling between threads is not performed by the kernel however by some library of user-mode code. Multiple threads in such an execution appear to the operating system as a single execution context. When the multithreaded process is running it settle on for itself which of its threads to execute using non-local jumps to switch stuck between threads according to its own pre-emptive or non-pre-emptive scheduling rules.

On the other hand the operating system kernel may make available support for threads itself. In this case the threads may be realize as separate processes that happen to share a complete or partial common address space or they may be realize as separate execution contexts within a single process. Any way the threads are organized they appear as completely independent execution contexts to the application.

Hybrid implementations are also possible, where a large number of threads are made available to the application using a smaller number of kernel threads. Runnable user threads are run by the first available kernel thread.

In Linux threads are executing within the kernel by a clone mechanism that creates a new process within the same virtual address space as the parent process. Unlike several kernel-based thread packages the Linux kernel doesn't make any distinction between threads and processes a thread is merely a process that didn't create a new virtual address space when it was initialized.

The major advantage of implementing threads in the kernel rather than in a user-mode library is that

• Kernel-threaded systems can take improvement of multiple processors if they are available.
• If one thread obstructs in a kernel service routine (for instance a system call or page fault) other threads are still capable to run.

A lesser benefit is the ability to assign different security attributes to each thread. User-mode implementations don't have these advantages. For the reason that such implementations run completely within a single kernel execution context merely one thread can ever be running at once even if multiple CPUs are obtainable. For the same cause if one thread enters a system call no other threads can run until that system call completes. Consequently one thread doing a blocking disk read will hold up each thread in the application. Nevertheless user-mode implementations do have their own merits. The most clear is performance- invoking the kernel's own scheduler to switch among threads involves entering a new protection domain as the CPU switches to kernel mode while switching between threads in user mode can be achieved simply by saving and restoring the main CPU registers. User-mode threads may as well consume less system memory- most UNIX systems will reserve at least a full page for a kernel stack for each kernel thread and this stack mayn't be page-able.

The hybrid approach executing multiple user threads over a smaller number of kernel threads allows a balance between these tradeoffs to be achieved. The kernel threads will permit multiple threads to be in blocking kernel calls at once as well as will permit running on multiple CPUs as well as user-mode thread switching can occur within each kernel thread to perform lightweight threading without the overheads of having too many kernel threads. The drawback of this approach is complexity giving control over the trade off complicates the thread library's user interface.