Do you know the ins and outs of threads?

[[280855]]

The process has been a little troubled recently, frowning all day long, and a little absent-minded when accessing memory.

Memory was a smart guy, and he got straight to the point and asked, "Process, what problems have you encountered recently? I see that you've been feeling a little down lately, so just tell me what the problem is, and I'll let everyone come together to help you think of a solution."

The process sighed and said, "Alas, isn't it said recently that the CPU single-core frequency has reached a bottleneck? Humans use multi-core cores to make up for the performance deficiencies of single-core processors. Hasn't our CPU been upgraded to quad-core?"

"Yes, this is a good thing. Now we can process up to 4 processes in parallel, and the efficiency is much higher than before. Isn't this good?" Memory asked doubtfully.

"It's good, but every time I run it on the CPU, I can't help but think, if the single-core frequency doesn't increase, won't my total running time remain the same? In the future, applications will become larger and larger, and consume more and more CPU resources. For example, those large game processes require a lot of calculations in a short period of time. What should I do if a single core can't support it? Let's not talk about the future, let's talk about myself. I also want to be able to finish running earlier and rest earlier."

tobe Note: Obviously the running time of a single process is reduced, but the main emphasis here is on the time the process occupies the CPU.

Memory nodded and agreed: "I didn't think of this problem. Multi-core processors are indeed not very friendly to a single process. Then we have to find a way to allow you to use several cores at the same time. But I can't think of a good solution for the time being, so let's discuss it with everyone."

At the discussion meeting, Memory explained to everyone the problems that the process was currently facing.

"How can a process run in parallel?" The process scheduler was the first to ask: "I can't put a process on four cores. This is not only meaningless, but also hinders the execution of other processes."

For more information about the process scheduler, see this article: Process Scheduling, Confessions of a Scheduler

The operating system is well-informed and said, "It is definitely impossible to put a process on several cores at once. I think our goal is to allow multiple cores to help a process run without conflict. Then we have to "split" the process and put it on several cores."

The operating system said this and drew a picture:

Process Splitting

"Look, if the two functions fun1 and fun2 are not related to each other, we can let two cores execute them at the same time, isn't this parallelism?"

"You mean to split a process into several processes?"

The operating system shook its head and said, "Instead of splitting them into multiple processes, the cost of process switching is too high. Besides, these split functions share the same address space and are naturally able to share data. If they are split into processes, we have to consider the communication problem between processes, which is too troublesome. However, to distinguish them from processes, let's call them "threads"."

The process was shocked. It was going to split itself into threads? Wouldn't that mean it would be gone? It hurriedly asked, "Wouldn't that mean there would be no room for me to exist?"

The process scheduler was also panicking: "If there are no processes, will I also be retired?"

The operating system quickly explained: You misunderstood. What I want to split is the execution flow of the process. Doesn’t the process include resource ownership and execution flow? Resource ownership is still controlled by the process, and the execution flow is divided into several threads, like this:

Execution Flow

tobe Note: In the process model, a process has control over resources such as memory, I/O channels, I/O devices, and files, which is called "resource ownership." The "execution flow" can be seen as the execution process of a process on the CPU (intuitively, it is the statements in a high-level language).

The process suddenly realized: "That means I am still the controller of resources, and those threads are just my little brothers who help me work?"

"Yes, and from this perspective, you are still a single-threaded process."

After listening for so long, Memory asked: "When creating a process, I need to save the process PCB. Then, in order to create a thread, do I have to create a TCB (Thread Control Block)?"

"Of course, the information needed for thread switching must be stored in the TCB. But don't worry, the TCB is much smaller than the PCB, so thread switching will be much faster than process switching."

Multithreaded process model

After listening to this, everyone felt that the "thread" model perfectly solved the current problem and said, "Why don't we add a thread model to the operating system now and solve the process problem as soon as possible."

But the operating system looked hesitant and said, "The thread model is just an assumption of ours. If we add it rashly, there may be problems. It would be bad if the system crashes. We still have to focus on stability... But we still have to try this model. Otherwise, let's create a thread library first and rely on a user-level application - the thread scheduler to manage these threads."

The process asked in confusion: "But in this case, I am still assigned to a single core. Even if there are multiple threads, they can only run on a single core. Besides, if one of these threads is blocked, in your opinion, the entire process is blocked, and the other threads, even if they are in the ready state, will not get CPU resources."

The operating system thought about it carefully and said, "There is no way. User-level threads do have these two disadvantages, but compared to letting the kernel implement threads, user-level threads also have their advantages - thread switching does not require me to perform state transitions (from user state to kernel state), and the overhead is small. In addition, the thread library can have multiple scheduling algorithms and can tailor scheduling algorithms for applications."

tobe Note: There is a solution to thread blocking called jacketing, which can convert a blocking system call into a non-blocking system call. For example, instead of calling the system-level I/O routine directly, the thread calls the application-level I/O jacket routine. This jacket routine will check whether the I/O device is busy. If it is busy, it will not perform the I/O operation and instead schedule other threads, avoiding process blocking caused by waiting for the I/O device.

User-level threads were soon put into use, and the pthread (POSIX thread) library in the Linux system was a great success. The operating system made a major decision - to support kernel-level threads.

Kernel-level threads solve the problem of process parallelism. In addition, since the kernel can see the existence of threads, if one thread is blocked, other threads in the same process can still run.

User-level threads and kernel-level threads

Process said that he is very happy now.