Follow+Star public account, don’t miss exciting content

Reprinted from | The Last Bug

Today, I will explain the concepts of threads, processes, and coroutines in OS, and see which one tasks in RTOS belong to.

Many friends encounter various program forms while learning OS, such as processes, threads, coroutines, monitors, fibers, oh my god! If you are not familiar with them, it is really difficult to distinguish. Today, the author mainly discusses the three concepts that everyone often encounters: processes, threads, and coroutines. The other forms will be gradually supplemented in later articles. Let’s take a look at the processes in Windows (Linux is similar), as shown in the figure below:

We can see that each row represents a process, and a process contains multiple threads. So what is the relationship between processes, threads, and coroutines? The author has drawn a simple diagram for your reference.

Before explaining processes, let’s first look at the concepts of concurrency and parallelism. The literal meaning of concurrency is that things happen together, focusing on a feeling. For a single-core CPU, the processing of instructions is executed sequentially. It is similar to a time-sharing processing, giving users the appearance of simultaneous occurrence, which is concurrency.

Parallelism refers to instructions running together at the same time, which usually occurs in multiprocessor systems.

A process is a dynamic execution process of a program. The process does not exclusively execute continuously on the CPU. The OS manages processes and often interrupts the current process to monitor and schedule multiple processes. In the kernel, there is a structure called Process Control Block (PCB) (if you study RTOS, you should have heard of Task Control Block (TCB), which will be mentioned later), this structure contains almost all the information and resources of the process. The OS obtains process information and manages processes through this control block.

The design of processes is to allow each application to better isolate from each other. For example, if the browser crashes suddenly while browsing the web, it will not affect my music player. The previous article published by the author on OS memory management explains that each process has its own independent memory space, and through the Memory Management Unit (MMU) and the page table mechanism, isolation is formed between each process.

If concurrent multi-processes need to save the current process’s site information, such as registers, stacks, and update page tables, it even needs to swap processes from external storage (such as disk) to run. This incurs a large overhead for the CPU, so to reduce overhead, concurrent threads within the process were created.

The purpose of processes is to isolate concurrency, and threads can be said to implement shared concurrency. All threads share the resources belonging to the process. Threads are the stripping of the process instruction stream, and threads have corresponding structure information management TCB similar to TCB in RTOS.

Because threads share resources, there will be mutual influence between threads. If one thread crashes, it is very likely to affect other threads in the same process; at the same time, there will be competition issues for reading and writing shared resources, which will lead to a series of solutions for handling shared resources, such as critical sections, mutex signals, etc.

Currently, most OS manage, schedule, and execute threads through the kernel, which incurs many system calls and time consumed in switching from user mode to kernel mode. To further reduce overhead, the concept of coroutines emerged to achieve better concurrency directly in user mode.

From the previous overview relationship diagram, we know that a thread can run multiple coroutines. In fact, a function call is a coroutine in its initial state. When function A calls function B, it can be considered that task A switches to task B for execution, and then returns to task A after execution. However, this task call always starts from the initial state. If a function actively gives up CPU by saving the current site, such as register values, and then restores to another function’s register state, it achieves concurrent execution of functions in any state, thus implementing coroutines. Okay, the explanation is a bit convoluted, let’s draw a diagram to understand:

Characteristics of Coroutines:

• Coroutines are concurrent executions in user mode, with less overhead compared to threads;

• Coroutines actively give up occupation, and do not require lock processing for related resources;

• Very suitable for IO-intensive tasks, such as the classic producer-consumer dual-thread model. If using coroutines, produce immediately and let the consumer handle it, which is very efficient.

For current mainstream RTOS like ucos, freeRTOS, RT-thread, etc., they belong to concurrent threads. In fact, looking at the name of RT-thread, it indicates real-time threads.

• Firstly, on MCU resources, each task is shared, which can be considered a single-process multi-thread model.

• MCUs generally do not have memory management modules (MMUs), making it difficult to achieve process safety. If implemented in software, the overhead is too large, which is unnecessary for MCUs. This is also why running a task program can cause the entire program to fail.

Some friends may have many doubts about these concepts. It is not that they do not understand these concepts, but rather that they are confused about the operating principles of OS. So if you are interested in this part, you can look for related books for systematic study. Keep it up!

Disclaimer:This article’s material comes from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact me for deletion.

Reply in the background with 『RTOS』『Operating System』 to read more related articles.

Click “Read the original text” to see more shares. Welcome to share, favorite, like, and watch.