Implementation model of thread in operating system

Turn from 55802984

1. Why do I need a thread?

The first question to answer is why the operating system requires a thread. If you have to say why you need a thread, it's better to say why there are other processes in the process. Other mini-processes included in these processes are threads. The process has the following drawbacks:

1, the process can only do one thing in a single time (executing a program execution flow), and if you want to do two or more things at the same time, the process is not enough.
2. If the process is blocked during execution, such as waiting for input, the entire process will be suspended and cannot continue execution. This way, even if some of the work in the process does not depend on the input data, it cannot be pushed forward.
In order to solve this problem, people invented the thread. A thread is a mini-process because there are many similarities between threads and processes, such as the state of threads and processes running, ready, blocking. These states are very simple to understand, when the resources required by the process are not in place, will be blocking state, when the resources required by the process is in place but the CPU is not in place is ready state, when the process has both the required resources, and the CPU, it is running state. With multi-threading, each thread only needs to deal with its own part of the task that should be done, instead of worrying about conflicts with other threads. The programming model is therefore simplified.
More specifically, the benefits of threading are as follows:

1, in many programs, multiple threads need to be synchronized or mutually exclusive to complete the work, and the decomposition of the work into different threads, undoubtedly simplifying the programming model.
2, because the thread is more lightweight than the process, the cost of creating and destroying threads becomes smaller.
2, threads improve performance, although the threads are parallel on the macro, but the micro is serial (single CPU or single core). Threads do not improve performance from a CPU perspective, but if some threads involve waiting for resources (such as IO, waiting for input), multithreading allows other threads in the process to continue executing rather than the entire process being blocked, thereby increasing CPU utilization and improving performance from this perspective.
3, in the case of multi-CPU or multi-core, the use of threads is not only in the macro-parallel, but also in the micro-parallel.
The process has its own independent memory address space, while the thread shares the memory address space of the process.

2, the classic threading model

Another view of process and thread is that the process model is based on two different concepts: the organization and execution of resources. In an operating system where there were no threads in the past, the organization and execution of the resources was done by the process. But there are times when you need to differentiate between these two, which is why you need to introduce threads. A process is a unit for organizing resources that are organized together with related resources: memory address space, programs, data, and so on, which are organized in a process that makes it easier for the operating system to manage these resources. threads, however, are a single line that executes in each process. Threads share most of the resources in a process, but threads also need some of their own resources, such as program counters that identify the next execution instruction, some registers that hold local variables, and stacks that represent the history of execution.

In summary: A process is the smallest unit of organization resources, and a thread is the smallest unit that schedules CPU execution. In fact, in one process, multiple threads are parallel to each other in the operating system, but the threads share the address space, and the process shares resources such as physical memory, printers, keyboards, and so on. Each process and thread has its own resources, as shown in table 1.

Table 1

Resources that the process occupies	Resources that the thread occupies
Address space	Stack
Global variables	Register
Open a file	Program counter
Signal Volume	State
Account information

Where a thread can share a process exclusive resource. Our common term "multithreading" generally refers to concurrent execution of multiple threads in the same process. A thread is an execution context within a process, or a sequence of execution. All threads within the same address space constitute a process. A thread is the smallest unit of CPU switching, and a process is the smallest unit of resource allocation.

For example: When we use Word, we are actually opening multiple threads. One of these threads is responsible for displaying, one accepting input, and one timed disk. These threads work together (at the same time compete with the CPU), allowing us to feel that the input and screen display occur simultaneously without typing some characters and waiting for a moment to see the screen display.

3, thread management and implementation methods

To manage threads is to maintain a variety of thread information, the data structure that holds this information is called the thread control block. Threads share a process space, so many resources are shared (such as address space, global variables, files, and so on), and these shared resources are stored in the Process Control block. There are also some resources and information that are not shared (such as program counters, registers, etc.) that need to be stored in the thread control block. There are two options for managing threads: One is to let the process manage the threads themselves, and the other is to have the operating system manage the threads. Managed by the process itself is the user-state thread implementation, managed by the operating system is the kernel-state thread implementation.

3.1 Thread implementation in user space

When a thread is implemented under user space, the operating system knows nothing about the thread, and the operating system sees only the process and cannot see the thread. All threads are implemented under user space. In the operating system it appears that each process has only one thread. Most of the past operating systems are implemented in this way, and one of the benefits of this approach is that even though the operating system does not support threading, it is possible to support threads through library functions. In this mode, each process maintains a thread table that tracks the threads in this process, which contains resources that are exclusive to each thread in table 1, such as stacks, registers, states, and so on, as shown in 1.

Figure 1 Thread implementation in user space

This mode calls the system procedure to block itself when a thread finishes its work or waits for it to be blocked, and then hands the CPU to another thread. User threads are seen in a number of historic operating systems, such as UNIX operating systems. The benefit of this pattern, first, is that process switching takes place in the user space much faster than in the operating system kernel. Second, implementing threads in user space allows programmers to implement their own thread scheduling algorithms. For example, a process can implement a garbage collector to collect threads. Also, when the number of threads is too high, because the thread table is maintained in user space, it does not occupy a large amount of operating system space. Finally, flexibility can be applied on any operating system because the operating system does not need to know the existence of a thread.

The most deadly disadvantage of this mode is that the operating system does not know the existence of a thread, so when a thread in a process makes a system call, such as a missing fault that causes the thread to block, the operating system blocks the entire process, even though the other threads in the process are still working. It also makes programming difficult, and when we write programs we have to think carefully about when we should let the CPU be used by other threads. Another problem is that if a thread in the process does not release the CPU for a long time, because the user space does not have a clock interrupt mechanism, it causes other threads in the process to wait without CPU.

3.2 Thread implementations in the operating system kernel

In this mode, the operating system knows the existence of the thread. At this point the thread table exists in the operating system kernel, as shown in 2. Thread should be the basic unit of CPU scheduling, the operating system to manage threads, it is necessary to maintain a variety of maintenance threads, the thread control block is stored in the operating system kernel space. This allows the operating system kernel to maintain both the process control block and the thread control block.

Figure 2 Thread implementation in the operating system kernel space

In this mode, all calls that are likely to block threads are implemented in the same way as system call, which can be much more expensive than runtime calls (System runtime call) that implement a thread that causes blocking in user space. When a thread is blocked, the operating system can choose to hand the CPU to other threads in the same process, or to other threads in the process, and when the thread is implemented in user space, the schedule can only be executed in this process until the operating system deprives the CPU of the current process.

Because it is more expensive to implement processes in kernel mode, it is a good practice to recycle threads, and when a thread needs to be destroyed, it simply modifies the tag bit instead of destroying its contents directly, and when a new thread needs to be created, it also modifies the token bit of the thread that was "destroyed". The advantage of a kernel-state thread implementation is that user programming is simple and user programmers do not have to worry about thread scheduling when they are programming, that is, without worrying about when the thread will execute and when it will hang. If one thread performs a blocking operation, the operating system can schedule another thread to execute gracefully. Because the operating system can monitor all threads.

This mode also has some drawbacks, such as low efficiency. Because threads are implemented in the kernel state, each thread switchover needs to fall into the kernel, which is dispatched by the operating system. Second, it takes up memory resources that are scarce in the kernel. The operating system needs to maintain the thread table, and the memory space occupied by the operating system is fixed once the load is completed and cannot be changed dynamically. Because the number of threads is significantly higher than the number of processes, the operating system kernel space is quickly exhausted as the number of threads increases.

3.3 Threading Implementation model for modern operating systems-Mixed mode

Given the flaws in both user and kernel states, modern operating systems use the combination of the two. The execution system of the user state is responsible for the switch of the process internal thread during non-blocking, and the kernel operating system is responsible for blocking the switch of the thread, that is, we implement both kernel State and user state thread management. The number of kernel-state threads is small, and the number of user-state threads is large. Each kernel-state thread can serve one or more user-state threads. In other words, the user-state thread is multiplexed to the kernel-state thread. In mixed mode, the processes in user space manage their own threads, and the operating system kernel has a subset of kernel-level threads, as shown in 3.

For example, if a process has 5 threads, we can divide 5 threads into two groups, one set of 3 threads, and another set of 2 threads. Each group of threads uses one kernel thread. In this way, the process will use two kernel threads. If one thread is blocked, the threads that belong to the same group are blocked, but the other set of threads can continue to execute. In this mode, when allocating threads, we can Cheng the thread that needs to perform the blocking operation as the kernel thread, and the line Cheng that does not perform the blocking operation is the user-state thread. In this way, we can obtain the advantages of two kinds of situation realization, and avoid its disadvantage.

Figure 3 A hybrid model of thread implementation

In this mode, the operating system sees only kernel threads. User-space threads run based on operating system threads. As a result, programmers can decide how many user-space threads and operating system threads to use, which is undoubtedly more flexible. The implementation of user-space threads is the same as in the previous implementation thread in user space, and can also be customized.

Implementation model of thread in operating system