Illustrated explanation of the past and present of four IO models

Recently, I have come to believe that when explaining technology-related issues, plain language is certainly important, easy to understand, and makes people want to read on. However, almost everything has two sides. When you see the benefits, you might as well think about whether it also introduces bad aspects.

For example, in a blog, using too much colloquial language will make it easier for you to read and understand. But this is what other people have understood and digested, and they have completely understood it. You may not be able to see the whole picture from this information. Therefore, appropriate colloquial language is good, but the degree must be controlled.

Next, cut to the main text.

I believe you often see this question:

What is the difference between BIO, NIO and AIO?

When you see this question, the following words may come to your mind. For example, BIO will block if it gets data from the kernel until the data is ready and returns. Another example is NIO, the kernel will not block if the data is not ready, and the calling program will keep asking the kernel whether the data is ready.

Although it is correct and the number of words is short, you are memorizing these concepts instead of understanding them. In fact, terms like BIO and NIO have a common name - IO model, which has a total of:

IO Model

Since signal-driven IO is not commonly used in practice, we mainly talk about the following four models:

1. Synchronous blocking
2. Synchronous non-blocking
3. IO multiplexing
4. Asynchronous IO

Here we use examples to understand these four IO models:

Assume that the client is sending some data to the server at this time, and the data has passed through the client's protocol stack and network card and has gradually arrived at the kernel buffer on the server side.

If you are not clear about the difference between user state and kernel state, you can read "Briefly talk about the difference between user state and kernel state"

If you are interested in the details of how data is transmitted in the network, you can read my previous article "What does the request data packet go through from sending to receiving?"

Synchronous blocking BIO

We need to know that the kernel is actually divided into two stages when processing data:

• Data preparation
• Data replication

In network IO, data preparation may mean that the client has some data that has not been sent yet or is in the process of being sent, and the data in the current kernel buffer is incomplete; while data replication is to copy the data in the kernel buffer to the user buffer.

When the calling thread initiates a read system call, if the kernel data is not ready at this time, the calling thread will be blocked and wait for the kernel buffer data. After the kernel data is ready, the kernel buffer data will be copied to the user buffer. During this process, the calling thread is still blocked until the data copy is completed. The whole process is represented by a diagram as follows:

Synchronous non-blocking NIO

I believe everyone knows that there is a package called nio in Java, but that is not the same concept as the NIO we are discussing now.

What we are discussing now is Non-Blocking IO, which stands for synchronous non-blocking and is a basic IO model. The nio package is New IO, and the IO model in it is actually IO multiplexing. Don't confuse them.

With the foundation of BIO, let's look at the picture directly this time:

NIO

Let’s discuss it in two stages.

Data preparation stage: At this time, the user thread initiates a read system call, and the kernel immediately returns an error, telling the user state that the data has not been read yet. Then the user thread keeps initiating requests to inquire about the status of the kernel's current data.

Data copying phase. At this time, the user thread is still continuously initiating requests, but when the data is ready, the user thread will be blocked until the data is copied from kernel state to user state.

To summarize briefly, if the kernel-state data is not ready, the user thread will not be blocked; but if the kernel-state data is ready, even if the current IO model is synchronous non-blocking, the user thread will still enter a blocked state until the data copy is completed, which is not absolutely non-blocking.

So what are the benefits of NIO? Obviously, it has good real-time performance and will return immediately if the kernel state data is not ready. But there is a double side to this. Frequent kernel polling will occupy a lot of CPU resources and reduce efficiency.

IO multiplexing

IO multiplexing actually solves the problem of frequent CPU polling in NIO. In the previous BIO and NIO, only one system call was involved - read. In IO multiplexing, a new system call - select is introduced.

Read is used to read data in the kernel buffer, and select can be understood as the keyword of the same name in MySQL, which is used to query the ready status of IO.

In NIO, if the kernel state data is not ready, the user thread will poll continuously, thus fully utilizing the CPU. However, after calling select in IO multiplexing, the user thread will be blocked as long as the data is not ready, thus avoiding frequent polling of the current IO status. This can be expressed in a diagram as follows:

IO multiplexing

Asynchronous AIO

The implementation of this model is asynchronous, as its name suggests. After the user thread initiates the read system call, it will not be blocked, but will return immediately regardless of whether the kernel buffer data is ready.

After receiving the request, the kernel will start preparing the data. When the data is ready and the copy is completed, the kernel will send a signal to the user thread, or call back the interface registered by the user thread to notify it. After receiving the notification, the user thread can read the data in the user state buffer.

AIO

Because of this implementation method, asynchronous IO is sometimes also called signal-driven IO. I believe you have also discovered that the most important thing about this method is the support of the OS. If the OS does not support it, it will be a complete failure.

Linux introduced asynchronous IO in version 2.6, but it was not considered true asynchronous IO at that time because the kernel did not support it. The underlying system was actually implemented through IO multiplexing. It was not until Linux 5.1 that true AIO was implemented through io_uring.

【Editor's recommendation】

1. Hongmeng official strategic cooperation and construction——HarmonyOS technology community
2. Quickly understand "little character endian" and "big character endian" and their use in Go language
3. Another "unmanned factory" is born. What will the remaining workers do?
4. Better than netstat? Detailed explanation of Linux network status tool ss
5. Spring Boot's five hot deployment methods, rapid development is productivity!
6. The temptation of open source - database