Why must User Threads be mapped to Kernel Thread?

A kernel thread is an actual thread that is capable of being scheduled and executed by the processor. User programs can make their own schedules too. However, these aren't kernel threads. Each user thread can't actually run on its own that's why it needs a kernel-level thread.

So for a user-level thread to make progress, the user program has to have its scheduler take a user-level thread and run it on a kernel-level thread, and then we have different mappings to achieve this. Before going further, you need to know briefly about user thread, kernel thread, and their mapping.

What is Thread?

A thread is the basic atomic unit of CPU utilization in computer systems. Mostly we consider a process to be the basic unit for CPU utilization, but a process may be further divided into multiple threads of execution. A process can be divided into different tasks or units that can execute independently, and these units are called threads.

A thread is a lightweight process that a scheduler can manage independently. It improves the application performance using parallelism. Thread shares information like data segment, code segment files, etc., with its peer threads while it contains its own registers, stack, counter, etc. The two main types of threads created in a computer system are:

1. User threads
2. Kernel threads

Threads can be created in the address space of the process itself, i.e., inside the process kernel involvement or without kernel involvement.

What are User Threads?

User threads are the threads created by the user with help from a user library and are visible just to the creating process and its run time environment, and the kernel has no idea about the creation of these threads. User threads just stay in the address space of the creating process and are run and managed by the creating process without kernel involvement.

User-level threads are small and much faster than kernel-level threads. They are represented by a program counter (PC), stack, registers, and a small process control block.

Advantages

Some of the advantages of user-level threads are as follows:

• User-level threads are easier and faster to create than kernel-level threads. They can also be more easily managed.
• User-level threads can run on any operating system.
• There is no kernel-mode privileges required for thread switching in user-level threads.

Disadvantages

User-level threads have the following disadvantages, such as:

• Multithreaded applications in user-level threads cannot use multiprocessing to their advantage.
• The entire process is blocked if one user-level thread performs a blocking operation.

What are Kernel Threads?

On the other hand, kernel-level threads are handled by the operating system directly, and the kernel does thread management. The kernel manages the context information for the process and the process threads. Because of this, kernel-level threads are slower than user-level threads.

Advantages

Some of the advantages of kernel-level threads are as follows:

• Multiple threads of the same process can be scheduled on different processors in kernel-level threads.
• The kernel routines can also be multithreaded.
• If a kernel-level thread is blocked, another thread of the same process can be scheduled by the kernel.

Disadvantages

Kernel level threads are also having the following disadvantages, such as:

• A mode switch to kernel mode is required to transfer control from one thread to another in a process.
• Kernel-level threads are slower to create as well as manage as compared to user-level threads.

How User Thread mapped to Kernel Thread

User threads are mapped to kernel threads by the threads library. The way this mapping is done is called the thread model.

The mapping of user threads to kernel threads is done using virtual processors. A virtual processor (VP) is a library entity that is usually implicit. The VP is a kernel thread or a structure bound to a kernel thread in the library. For a user thread, the VP behaves like a CPU.

There are the following possible thread models, and all models are used to map user-level threads to kernel-level threads.

1. M:1 model: In the M:1 model, all user threads are mapped to one kernel thread. The process can only run one user-level thread at a time because there is only one kernel-level thread associated with the process. A library scheduler handles the mapping, and the library completely handles all user-threads programming facilities. This model can be used on any system, especially on traditional single-threaded systems.
   
2. 1:1 model: In the 1:1 model, each user thread is mapped to one kernel thread. Every user-level thread executes on a separate kernel-level thread, or each user thread runs on one VP. Most of the user threads programming facilities are directly handled by the kernel threads. This model is the default model.
   
3. M: N model: In the M: N model, all user threads are mapped to a pool of kernel threads; all user threads run on a pool of virtual processors. The process is allocated m number of kernel-level threads to execute n number of user-level threads. A user thread may be bound to a specific VP, as in the 1:1 model. All unbound user threads share the remaining VPs.
   
   This is the most efficient and most complex thread model. The user thread programming facilities are shared between the threads library and the kernel threads. This model can be set by setting the AIXTHREAD_SCOPE environment variable to P.
4. Two-level: The two-level model is similar to the M: N model but also allows certain user-level threads to be bound to a single kernel-level thread.
   

In both the M: N model and the two-level model, there must be some way for the kernel to communicate with the user level thread manager to maintain an appropriate number of kernel threads allocated to the process. This mechanism is called scheduler activations.

The kernel provides the application with a set of kernel threads (virtual processors), and then the application has complete control over what threads to run on each of the kernel threads. The kernel controls the number of kernel threads in the set in response to the competing demands of different processes in the system.

The kernel notifies the user-level thread manager of important kernel events using upcalls from the kernel to the user-level thread manager.

For example, let's study an example of how scheduler activations can be used.

1. The kernel has allocated one kernel thread to a process with three user-level threads.
2. The three user-level threads take turns executing on the single kernel-level thread.
   
3. The executing thread makes a blocking system call.
4. The kernel blocks the calling user-level thread and the kernel-level thread used to execute the user-level thread.
5. Scheduler activation:the kernel decides to allocate a new kernel-level thread to the process.
6. Upcall:the kernel notifies the user-level thread manager of which user-level thread is now blocked, and a new kernel-level thread is available.
7. The user-level thread manager moves the other threads to the new kernel thread and resumes one of the ready threads.
   
8. While one user-level thread is blocked,
9. The other threads can take turns executing on the new kernel thread.
   

Why must User Threads be mapped to a Kernel Thread?

User threads need to be mapped to kernel threads because it's the kernel that schedules the thread for execution onto the CPU, and for that, it must know about the thread that it is scheduling.

All the user threads created by a process are executed over the same kernel-level thread appointed to the whole process. Whenever it's the turn for the specified process to execute on the CPU, its kernel thread is scheduled onto the CPU. All the other user threads inside the process have to be mapped one by one onto the kernel thread appointed to the creating process if they have to be executed.

Since all of them are controlled by the creating process itself, the user threads must be mapped onto the appointed kernel thread one by one and, therefore, executed.