Let’s talk about processes, threads, coroutines and concurrency models in Node.js

Node.js has now become a member of the toolbox for building high-concurrency network application services. Why has Node.js become the darling of the public? This article will start with the basic concepts of processes, threads, coroutines, and I/O models, and give you a comprehensive introduction to Node.js and the concurrency model.

Process

We generally call a running instance of a program a process. It is a basic unit for resource allocation and scheduling by the operating system. It generally includes the following parts:

• Program: the code to be executed, which is used to describe the process requirements. Completed functions;
• data area: data space processed by the process, including data, dynamically allocated memory, user stack of processing functions, modifiable programs and other information;
• process table items: in order to implement the process model, the operating system maintains a called It is a进程表table. Each process occupies a进程表项(also called进程控制块). This entry contains important process status such as program counter, stack pointer, memory allocation, status of open files, and scheduling information. information to ensure that after the process is suspended, the operating system can correctly revive the process.

The process has the following characteristics:

• Dynamicity: The essence of a process is an execution process of a program in a multi-programming system. Processes are dynamically generated and destroyed;
• Concurrency: Any process can be executed concurrently with other processes;
• Independence: A process is a basic unit that can run independently, and it is also an independent unit for resource allocation and scheduling by the system;
• asynchrony: due to the mutual constraints between processes, the process has intermittent execution, that is, the processes execute at independent and unpredictable speeds Push forward.

It should be noted that if a program is run twice, even if the operating system can enable them to share code (i.e. only one copy of the code is in memory), it cannot change that the two instances of the running program are two different processes fact.

During the execution of the process, due to various reasons such as interruptions and CPU scheduling, the process will switch between the following states:

• Running state: The process is running at this moment and occupying the CPU;
• Ready state: The process is ready and can be run at any time, but it is temporarily stopped because other processes are running;
• Blocked state: The process is blocked at this moment, unless an external An event (such as keyboard input data has arrived) occurs, otherwise the process will not be able to run.

From the process state switching diagram above, we can see that a process can switch from running state to ready state and blocked state, but only ready state can be directly switched to running state. This is because:

• switching from running state to ready state is caused by the process scheduler. Yes, because the system thinks that the current process has taken up too much CPU time and decides to let other processes use the CPU time; and the process scheduler is part of the operating system, and the process does not even feel the existence of the scheduler;
• it switches from running state to blocking The process cannot continue to execute due to its own reasons (such as waiting for user keyboard input), and can only hang and wait for a certain event (such as keyboard input data has arrived) to occur; when a related event occurs, the process is first converted to ready state, if no other process is running at this time, it will be converted to the running state immediately, otherwise the process will remain in the ready state, waiting for scheduling by the process scheduler.

Threads

Sometimes, we need to use threads to solve the following problems:

• As the number of processes increases, the cost of switching between processes will become larger and larger, and the effective usage of the CPU will become lower and lower. In serious cases, the system may be damaged. Phenomenons such as suspended animation;
• each process has its own independent memory space, and the memory spaces between processes are isolated from each other. Some tasks may need to share some data, and data synchronization between multiple processes is too much. Cumbersome.

Regarding threads, we need to know the following points:

• A thread is a single sequential control flow in program execution. It is the smallest unit that the operating system can perform calculation scheduling. It is included in the process and is the actual running unit in the process;
• a process It can contain multiple threads, each thread executing different tasks in parallel;
• all threads in a process share the process's memory space (including code, data, heap, etc.) and some resource information (such as open files and system signals);
• Threads in one process are not visible in other processes.

Now that we understand the basic characteristics of threads, let’s talk about several common thread types.

Kernel state threads

Kernel state threads are threads directly supported by the operating system. Its main features are as follows:

• thread creation, scheduling, synchronization, and destruction are completed by the system kernel, but its overhead is relatively expensive;
• the kernel can map kernel state threads to various processes. On the processor, one processor core can easily correspond to one kernel thread, thereby fully competing for and utilizing CPU resources;
• only the code and data of the core can be accessed;
• the resource synchronization and data sharing efficiency is lower than that of the process. .

User-mode threads

User-mode threads are threads completely built in user space. Its main characteristics are as follows:

• thread creation, scheduling, synchronization, and destruction are completed by user space, and its overhead is very low;
• because user-mode threads are maintained by user space, the kernel does not The existence of user-mode threads is not perceived, so the kernel only schedules and allocates resources to the process to which it belongs. The scheduling and resource allocation of threads in the process are handled by the program itself. This is likely to cause a user-mode thread to be blocked in the system call. , there is a risk that the entire process will be blocked;
• it can access all shared address spaces and system resources of the process it belongs to;
• resource synchronization and data sharing are more efficient.

Lightweight Process (LWP)

A lightweight process (LWP) is a user thread built on and supported by the kernel. Its main features are as follows:

• User space can only use kernel threads through lightweight processes (LWP). It can be regarded as a bridge between user-mode threads and kernel threads. Therefore, only by supporting kernel threads can there be a lightweight process (LWP).

• Most operations of lightweight processes (LWP) require user-mode space to initiate the system. Call, this system call is relatively expensive (requires switching between user mode and kernel mode);

• each lightweight process (LWP) needs to be associated with a specific kernel thread, therefore:

  • like kernel threads, CPU resources can be fully competed and utilized system-wide;
  • each lightweight process (LWP) is an independent thread scheduling unit, so even if a lightweight process (LWP) is blocked in a system call, It does not affect the execution of the entire process;
  • lightweight processes (LWP) need to consume kernel resources (mainly referring to the stack space of kernel threads), which makes it impossible for the system to support a large number of lightweight processes (LWP);

• they can access their own processes All shared address spaces and system resources.

Summary

Above, we briefly introduced the common thread types (kernel state threads, user state threads, lightweight processes). Each of them has its own scope of application. In actual use, you can freely use them according to your own needs. Use in combination, such as common one-to-one, many-to-one, many-to-many and other models. Due to space limitations, this article will not introduce too much about this. Interested students can study it by themselves.

Coroutine

, also called Fiber, is a program running mechanism built on threads that allows developers to manage execution scheduling, state maintenance and other behaviors by themselves. Its main features are

• : Execution scheduling does not require context switching, so it has good execution efficiency;
• because it runs on the same thread, there is no synchronization problem in thread communication;
• it is convenient to switch control flows and simplify the programming model.

In JavaScript, async/await that we often use is an implementation of coroutine, such as the following example:

function updateUserName(id, name) {
  const user = getUserById(id);
  user.updateName(name);
  return true;
}

async function updateUserNameAsync(id, name) {
  const user = await getUserById(id);
  await user.updateName(name);
  return true;
}

In the above example, the logical execution sequence within the functions updateUserName and updateUserNameAsync is:

• call the function getUserById and assign its return value to the variable user ;
• call the updateName method of user ;
• return true to the caller.

The main difference between the two lies in the state control during actual operation:

• during the execution of function updateUserName , it is executed in sequence according to the logical sequence mentioned above;
• during the execution of function updateUserNameAsync , it is also executed in sequence according to the logical sequence mentioned above. Execution, but when encountering await , updateUserNameAsync will be suspended and save the current program state at the suspended location. It will not wake up updateUserNameAsync again until the program fragment after await returns and restore the program state before suspending, and then Continue to the next program.

From the above analysis, we can boldly guess: What coroutines need to solve is not the program concurrency problems that processes and threads need to solve, but the problems encountered when processing asynchronous tasks (such as file operations, network requests, etc.); in Before async/await , we could only handle asynchronous tasks through callback functions, which could easily make us fall into回调地狱and produce a mess of code that is generally difficult to maintain. Through coroutines, we can achieve synchronization of asynchronous code. Purpose.

What needs to be kept in mind is that the core capability of coroutines is to be able to suspend a certain program and maintain the state of the program's suspension position, and resume it at the suspended position at some time in the future, and continue to execute the next segment after the suspension position. program.

I/O model

A complete I/O operation needs to go through the following stages:

• the user process (thread) initiates an I/O operation request to the kernel through a system call;
• the kernel processes the I/O operation request (divided into the preparation stage and the actual execution phase), and returns the processing results to the user thread.

We can roughly divide I/O operations into four types:阻塞I/O ,非阻塞I/O ,同步I/O , and异步I/O Before discussing these types, we first become familiar with the following two sets of concepts (here Assume that service A calls service B):

• 阻塞/非阻塞:

  • If A returns only after receiving a response from B, then the call is阻塞调用;
  • if A returns immediately after calling B (that is, there is no need to wait for B to complete execution) , then the call is非阻塞调用.

• 同步/异步:

  • If B notifies A only after execution is completed, then service B is同步;
  • if A calls B, B immediately gives A a notification that the request has been received, and then executes it through回调after the execution is completed. The result is notified to A, then service B is异步.

Many people often confuse阻塞/非阻塞with同步/异步, so special attention needs to be paid:

• 阻塞/非阻塞is for调用者of the service;
• 同步/异步is for被调用者of the service.

After understanding阻塞/非阻塞and同步/异步, let's look at the specific I/O 模型.

Blocking I/O

definition: After the user thread initiates an I/O system call, the user thread will be阻塞immediately until the entire I/O operation is processed and the result is returned to the user thread. Only after the user enters the (thread) process can阻塞state be released and continue to perform subsequent operations.

Features:

• Since this model will block the user's (thread) process, it does not occupy CPU resources;
• when performing I/O operations, the user's (thread) process cannot perform other operations;
• this model is only suitable for small concurrency Application, this is because one I/O request can block the incoming (thread) thread, so in order to respond to the I/O request in time, it is necessary to allocate an incoming (thread) thread to each request, which will cause huge resource usage , and for long connection requests, since the incoming (thread) resources cannot be released for a long time, if there are new requests in the future, a serious performance bottleneck will occur.

Non-blocking I/O

definition:

• After the user initiates an I/O system call in a thread (thread), if the I/O operation is not ready, the I/O call will return an error, and the user does not need to enter the thread (thread). Wait, but use polling to detect whether the I/O operation is ready;
• after the operation is ready, the actual I/O operation will block the user's thread until the execution result is returned to the user's thread.

Features:

• Since this model requires the user to continuously inquire about the I/O operation readiness status (usually using a while loop), the model needs to occupy the CPU and consume CPU resources;
• before the I/O operation is ready, the user needs to enter ( The thread) thread will not be blocked. When the I/O operation is ready, subsequent actual I/O operations will block the user from entering the thread (thread) thread;
• this model is only suitable for applications with a small amount of concurrency and which do not require timely response.

Synchronous (asynchronous) I/O

After the user process (thread) initiates an I/O system call, if the I/O call causes the user process (thread) to be blocked, then the I/O call is同步I/O , otherwise it is异步I/O .

The criterion for judging whether an I/O operation同步or异步is the communication mechanism between user threads and I/O operations. In the

• case of同步, the interaction between user threads and I/O is synchronized through the kernel buffer. , that is, the kernel will synchronize the execution results of the I/O operation to the buffer, and then copy the data in the buffer to the user thread. This process will block the user thread until the I/O operation Completed;
• in异步situations, the interaction between the user thread (thread) and I/O is directly synchronized through the kernel, that is, the kernel will directly copy the execution results of the I/O operation to the user thread (thread). This process will not Block the user's (thread) process.

The concurrency model of Node.js

Node.js uses a single-threaded, event-driven asynchronous I/O model. Personally, I think the reason for choosing this model is:

• JavaScript runs in single-threaded mode under V8, which implements multiple Threads are extremely difficult;
• most network applications are I/O intensive. How to reasonably and efficiently manage multi-thread resources while ensuring high concurrency is more complicated than the management of single-thread resources.

In short, for the purpose of simplicity and efficiency, Node.js adopts a single-threaded, event-driven asynchronous I/O model, and implements its model through the EventLoop of the main thread and the auxiliary Worker thread:

• After the Node.js process is started , the Node.js main thread will create an EventLoop. The main function of the EventLoop is to register the callback function of the event and execute it in a future event loop;
• the Worker thread is used to perform specific event tasks (other threads other than the main thread) (executed in a synchronous manner), and then return the execution results to the EventLoop of the main thread, so that the EventLoop can execute the callback function of the relevant event.

It should be noted that Node.js is not suitable for performing CPU-intensive (i.e., requiring a lot of calculations) tasks; this is because EventLoop and JavaScript code (non-asynchronous event task code) run in the same thread (i.e., the main thread), and any of them If one runs for too long, it may cause the main thread to block. If the application contains a large number of tasks that require long execution, it will reduce the throughput of the server and may even cause the server to become unresponsive.

Summary

Node.js is a technology that front-end developers have to face now and even in the future. However, most front-end developers only have superficial knowledge of Node.js. In order to let everyone better understand the concurrency model of Node.js, This article first introduces processes, threads, and coroutines, then introduces different I/O models, and finally gives a brief introduction to the concurrency model of Node.js. Although there is not much space to introduce the Node.js concurrency model, the author believes that it can never be separated from the basic principles. Mastering the relevant basics and then deeply understanding the design and implementation of Node.js will get twice the result with half the effort.

Finally, if there are any mistakes in this article, I hope you can correct them. I wish you all happy coding every day.