3 implementation models of Linux history on-line

I. Overview

Take Linux for example here. In Linux history, the first thread to use was linuxthreads, but some aspects of linuxthreads were limited by the kernel's features, which violated the SUSV3 pthreads standard. That is, it implements threads based on the characteristics of the kernel, and some places do not follow a uniform standard. Later, IBM developed the NGPT (Next Generation POSIX Threads), which was significantly better than Linuxthreads, a successor to Linuxthreads. But finally, there is a project NPTL (Native POSIX Threads Library) out, the performance is better than NGPT. The 2002 NGPT Project stopped developing, and the Linux thread we're using now is NPTL.

There were 3 models of thread implementations:

1. Multi-to-one (m:1) user-level threading model

2. One-to-one (1:1) kernel-level threading model

3. Multi-to-many (m:n) two-level threading model

The x pair y (x:y) is the x user thread corresponding to the Y kernel dispatch entity (Kernel scheduling entity, which is the object unit of the kernel allocating CPU).

Linuxthreads and NPTL are all using a one-to-one threading model, NGPT is a multi-to-many threading model!!!

Two. Multi-to-one user line class model

In a multi-threading model, all the details of thread creation, scheduling, and synchronization are all handled by the process's user space line libraries. Many of the operations of the user-state thread are transparent to the kernel because the kernel does not need to be taken over, which means that the kernel state and the user state are not required to switch frequently. Threads are created, dispatched, and synchronized very quickly. of course, some of the other operations of the thread go through the kernel, such as IO Read and write . This leads to a problem: when multithreading is executing concurrently, if one of the threads performs an IO operation, the kernel takes over the operation, and if the IO is blocked, the other threads of the user state are blocked because the threads correspond to the same kernel scheduler entity. On multiprocessor machines, the kernel does not know that the user state has these threads, cannot dispatch them to other processors, and cannot be dispatched by priority. There is no point in using this thread!

Three. One-to-one kernel-pole threading model

In a one-to-one model, each user thread corresponds to its own kernel dispatch entity . Each thread is dispatched by the kernel and can be dispatched to other processors. Of course, the result of scheduling by the kernel is that each operation of the thread will switch between the user state and the kernel state. In addition, the kernel maps scheduling entities for each thread, which can have an impact on system performance if a large number of threads are present. However, the model is more practical than many-to-one threading model.

Four. Multi-pair multi-polar threading model

Many-to-many models combine the advantages of 1:1 and m:1 to avoid their drawbacks. Each thread can have more than one dispatch entity, or multiple threads can have one scheduled entity. Sounds perfect, but thread scheduling needs to be implemented by the kernel State and the user configuration. It is conceivable that when multiple objects operate on one thing, there must be some other synchronization mechanism. The Division of User-State and kernel-state results in a complex implementation of the model. NPTL once also wanted to use the model, but it was too complex to make a wide range of changes to the kernel, so the use of a one-on model!!!

3 implementation models of Linux history on-line