If you want a Kung Pao Chicken Rice Bowl:
Synchronous blocking: you go to the restaurant to order food, and then wait there, while shouting: Okay!
Synchronous non-blocking: After ordering at the restaurant, go for a walk with the dog. But after slipping for a while, I went back to the restaurant and shouted: Okay!
Asynchronous blocking: When walking the dog, you receive a call from the restaurant saying that the meal is ready, and asks you to pick it up in person.
Asynchronous non-blocking: The restaurant called and said, we know your location, we will deliver it to you as soon as possible, and you can walk the dog with peace of mind.
In high-performance I/O design, there are two well-known modes, Reactor and Proactor. The Reactor mode is used for synchronous I/O, while the Proactor is used for asynchronous I/O operations.
Before comparing these two modes, we first understand a few concepts, what is blocking and non-blocking, what is synchronous and asynchronous, synchronous and asynchronous are for the interaction between the application and the kernel, synchronous refers to the user The process triggers the IO operation and waits or polls to see if the IO operation is ready, while asynchronous means that the user process starts to do its own thing after triggering the IO operation, and when the IO operation has been completed, it will be notified of the IO completion (asynchronous is characterized by notifications). Blocking and non-blocking refer to the different ways that a process takes according to the ready state of the IO operation when it accesses data. To put it bluntly, it is an implementation of a read or write operation function. In blocking mode, read or write The incoming function will always wait, and in non-blocking mode, the read or write function will immediately return a status value.
Generally speaking, the I/O model can be divided into: synchronous blocking, synchronous non-blocking, asynchronous blocking, asynchronous non-blocking IO
Synchronous blocking IO:
In this way, after the user process initiates an IO operation, it must wait for the completion of the IO operation, and only when the IO operation is actually completed can the user process run. JAVA's traditional IO model belongs to this way!
Synchronous non-blocking IO:
In this way, the user process can return to do other things after initiating an IO operation, but the user process needs to ask whether the IO operation is ready from time to time, which requires the user process to keep asking, thereby introducing unnecessary CPU resources waste. Among them, the current JAVA NIO belongs to synchronous non-blocking IO.
Asynchronous blocking IO:
In this way, after the application initiates an IO operation, it does not wait for the completion of the kernel IO operation. After the kernel completes the IO operation, the application will be notified. This is actually the most critical difference between synchronization and asynchrony. Synchronization must wait or actively Ask if IO is complete, so why is it blocking? Because it is done through the select system call at this time, and the implementation of the select function itself is blocking, and the use of the select function has the advantage that it can monitor multiple file handles at the same time (if from the perspective of UNP, select is synchronous operation. Because after the select, the process also needs to read and write data), thereby improving the concurrency of the system!
Asynchronous non-blocking IO:
In this mode, the user process only needs to initiate an IO operation and then return immediately. After the IO operation is truly completed, the application will be notified of the completion of the IO operation. At this time, the user process only needs to process the data. There is no need to perform actual IO read and write operations, because the real IO read or write operations are already done by the kernel. There is currently no support for this IO model in Java.
After figuring out the above concepts, let's go back and look at the Reactor mode and the Proactor mode.
(In fact, both blocking and non-blocking can be understood as concepts only under the category of synchronization. For asynchronous, there will be no blocking and non-blocking. For user processes, after receiving asynchronous notifications, they directly operate the process in the user space. Data is good.)
Let's first look at the Reactor pattern, which is used in synchronous I/O scenarios. Let's take a read operation and a write operation as an example to see the specific steps in Reactor:
Read operation:
1. The application registers the read-ready event and the associated event handler
2. The event separator waits for the occurrence of the event
3. When a read ready event occurs, the event separator calls the event handler registered in the first step
4. The event handler first performs the actual read operation, and then performs further processing based on the read content
The write operation is similar to the read operation, except that the first step is to register the write-ready event.
Let's take a look at the process of read and write operations in Proactor mode:
Read operation:
1. The application initializes an asynchronous read operation, and then registers the corresponding event handler. At this time, the event handler does not focus on the read ready event, but on the read completion event, which is the key to distinguishing it from Reactor.
2. The event separator waits for the read operation complete event
3. When the event separator waits for the read operation to complete, the operating system calls the kernel thread to complete the read operation (asynchronous IO is the operating system responsible for reading and writing data to the buffer passed in by the application for application operation, and the operating system plays the role of important roles), and put the read content into the buffer passed by the user. This is also different from Reactor. In Proactor, the application needs to pass the buffer.
4. After the event separator captures the read completion event, it activates the event handler registered by the application, and the event handler reads data directly from the buffer area without the need for an actual read operation.
Write operations and read operations in Proactor, but the event of interest is the write completion event.
As can be seen from the above, the main difference between Reactor and Proactor modes is who performs the real read and write operations. In Reactor, the application needs to read or write data by itself, while in Proactor mode, the application does not The actual read and write process needs to be performed, it only needs to read or write from the buffer area, and the operating system will read the buffer area or write the buffer area to the real IO device.
To sum up, synchronization and asynchrony are relative to the interaction between the application and the kernel. Synchronization needs to actively ask, and when asynchronous, the kernel notifies the application when an IO event occurs, while blocking and non-blocking are only the system. It's just how the function is implemented when calling the system call.
//From: http://blog.csdn.net/brainkick/article/details/9312407