[UNUX] processes and threads

Introduction

In traditional operating systems, processes have independent memory address space and a thread for control. However, in more cases, multiple threads Must be concurrently executed in the same address space. Therefore, threads are introduced into the operating system.

 

Why thread?

If it is necessary to say why a thread is needed, it is better to say why other processes need to be included in the process. Other mini processes contained in these processes are threads.

The thread is a mini process because there are many similarities between the thread and the process. For example, both the thread and the process are running, ready, and blocked. These statuses are easy to understand. When the resources required by the process are not in place, they will be blocked. When the resources required by the process are in place but the CPU is not in place, they will be ready, when a process has both the required resources and the CPU, it is running.

Here is a specific example:

For the LiveWriter I wrote a blog, LiveWriter needs to monitor the status of my typing input and automatically save the draft every five minutes. If this process has only one thread, when saving the draft, the hard disk needs to be accessed at this time, and the Time Thread accessing the hard disk is blocked, at this time, I will not respond to any input. This kind of user experience is unacceptable. Maybe we can use the keyboard or mouse input to interrupt the process of saving the draft, but this solution is not satisfactory. With multithreading, each thread only needs to process the tasks that should be completed in its own part, instead of worrying about conflicts with other threads. Therefore, the programming model is simplified. 1.

Figure 1. Two threads meet their respective functions

More specifically, the advantages of threads are as follows:

1. In many programs, multiple threads need to be synchronized or mutually exclusive in parallel to complete the work. However, decomposing these jobs into different threads undoubtedly simplifies the programming model.

2. Because the thread is more lightweight than the process, the cost of thread creation and destruction is reduced.

3. threads improve performance. Although threads are parallel at the macro level, they are serial at the micro level. Threads cannot improve performance from the CPU point of view, but if some threads are involved in waiting for resources (such as I/O, waiting for input), multithreading allows other threads in the process to continue to execute rather than the whole process is blocked, therefore, the CPU utilization is improved, which improves the performance.

4. In the case of multiple CPUs or multiple cores, the use of threads is not only parallel at the macro level, but also parallel at the micro level.

 

It is worth noting that if the above two threads are changed to two processes, the desired effect will not be achieved because the process has its own memory address space, the thread shares the memory address space of the process.

 

Classic thread model

Another perspective is that the process model is based on two different concepts: the organization and execution of resources. In a non-threaded operating system in the past, the organization and execution of resources were completed by processes. However, it is often necessary to differentiate the two, which is why threads need to be introduced.

A process is a unit used to organize resources. A process organizes related resources, including memory address space, programs, and data, organizing these processes makes it easier for the operating system to manage these resources.

A thread is a line executed in each process. Although the thread shares most of the resources in the process, the thread also needs some of its own resources, such as the program counter used to identify the next execution command, some registers containing local variables, stack used to indicate the execution history.

All in all: a process is the smallest unit of organizational resources, while a thread is the smallest unit of CPU execution.

In fact, in a process, parallel threads are similar to parallel threads in multiple processes in the operating system, but threads share the address space, while processes share the physical memory, printer, keyboard and other resources ......

The resources occupied by each process and thread are shown in table 1.

Resources occupied by processes	Resources occupied by threads
Address Space Global Variables Open File Sub-Process Semaphores Account Information	Stack Register Status Program counters

Table 1. Dedicated resources of processes and threads

 

Threads can share resources exclusively occupied by processes.

 

The commonly used term "multithreading" generally refers to the concurrent execution of multiple threads in the same process. 2.

Figure 2. A system without multiple threads can have only one thread

 

In a multi-threaded process, each thread uses the CPU in turn. In fact, threads are not parallel, but from a macro perspective, they are parallel.

In a multi-threaded model, each process has only one thread at the initial creation. This thread can create other threads by calling the system's library functions. The thread created by the thread must specify an address for it, because the new thread automatically works in the address space where it is created. Although one thread can create another thread, threads are usually parallel and there is no hierarchical relationship.

After a process completes its work, it can be destroyed by calling the system library function.

 

Several operating system implementation thread Modes

In the operating system, threads can be implemented in user mode, kernel mode, or in combination.

 

Thread implementation in user space

When a thread is implemented in a user space, the operating system knows nothing about the existence of the thread. The operating system can only see the process, but not the thread. All threads are implemented in the user space. In the operating system, each process has only one thread. In the past, most operating systems were implemented in this way. One of the advantages of this method is that even if the operating system does not support threads, it can also support threads through library functions.

In this mode, each process maintains a thread table to track threads in the process. This table contains resources exclusively occupied by each thread in Table 1, such as stacks, registers, and States, 3.

Figure 3. Implementing threads in user space

 

In this mode, when a thread completes its work or waits for it to be blocked, the calling system process blocks itself, and then the CPU is handed over to other threads.

The advantage of this mode is that process switching in user space is 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 recycle threads. In addition, when the number of threads is too large, because the thread table is maintained in the user space, it does not occupy a large amount of operating system space.

This mode has the most fatal disadvantage because the operating system does not know the existence of the thread. Therefore, when a thread in a process is called by the system, for example, if the thread is blocked due to page disconnection, the operating system will block the entire process, even if other threads in the process are still working. Another problem is that if a thread in a process does not release the CPU for a long time, because there is no clock interruption mechanism in the user space, other threads in the process will not get the CPU and will continue to wait.

 

Thread implementation in the operating system kernel

In this mode, the operating system knows the existence of a thread. The thread table exists in the operating system kernel, as shown in figure 4.

Figure 4. Implementation of threads in the operating system kernel

 

In this mode, all calls that may block threads are implemented in the System Call mode, compared with running call (System runtime call), which causes thread congestion in user space, the cost is much higher. When a thread is blocked, the operating system can choose to give the CPU to other threads in the same process or to other threads in the process. When the thread is implemented in the user space, scheduling can only be executed in this process until the operating system has deprived the CPU of the current process.

Because it is more costly to implement the process in kernel mode, another thread can be recycled. When a thread needs to be destroyed, it only modifies the tag bit instead of directly destroying its content, when a new thread needs to be created, you can also modify the flag bit of the thread that is "destroyed.

In this mode, there are still some drawbacks. For example, if the unit for Receiving System signals is process rather than thread, which thread in the process receives System signals? If a table is used for recording, which thread is used for system signal processing when multiple threads register?

 

Hybrid mode

Another implementation method is to mix the above two modes. In the user space, processes manage their own threads. in the operating system kernel, there are some kernel-level threads, as shown in Figure 5.

Figure 5. hybrid mode

 

In this mode, the operating system can only see the kernel thread. The user space thread runs based on the operating system thread. Therefore, programmers can determine the number of user space threads and operating system threads, which undoubtedly has greater flexibility. The scheduling of user space threads is the same as the preceding Implementation thread in user space, which can also be customized.