High-performance I/O design reactor and Procator

In High-performance I/O design, there are two well-known patterns reactor and Proactor modes, where the reactor mode is used to synchronize I/O, while Proactor is applied to asynchronous I/O operations.

Before you compare these two patterns, we first understand a few concepts, what is blocking and non-blocking, what is synchronous and asynchronous, synchronous and asynchronous are for application and kernel interaction, synchronization refers to the user process triggering IO operations and waiting or polling to see if the IO operation is ready, Asynchronous means that the user process triggers the IO operation and then begins to do its own thing, and when the IO operation has been completed, it will get an IO-completed notification (asynchronous feature is the notification). And blocking and non-blocking are aimed at the process when accessing the data, depending on how the IO operation is ready, it is a way to read or write a function that reads or writes to the function, and the read or write functions will wait instead of blocking, and the read or write function immediately returns a status value.

Generally speaking I/O model can be divided into: synchronous blocking, synchronous non-blocking, asynchronous blocking, asynchronous non-blocking IO

Synchronous Blocking IO:

In this way, the user process must wait for the IO operation to complete after an IO operation is initiated, and the user process will not run until the IO operation is actually completed. The Java traditional IO model belongs in this way.

Synchronous non-blocking IO:

In this way, the user process initiates an IO operation to return to doing other things, but the user process needs to ask the IO operation to be ready from time to time, which requires the user process to constantly ask, thus introducing unnecessary waste of CPU resources. The current Java NiO belongs to synchronous non-blocking io.

Asynchronous blocking IO:

This means that after the application initiates an IO operation, do not wait for kernel IO operations to complete, and so the kernel completes the IO operation will notify the application, this is actually synchronous and asynchronous the most critical difference, synchronization must wait or actively ask IO is completed, then why is it blocked? Because this is done by a select system call, and the Select function itself is implemented in a blocking way, the advantage of using the Select function is that it can listen for multiple file handles simultaneously (if the select is a synchronous operation from the UNP point of view). Because the process also needs to read and write data after the Select, it increases 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, and when the IO operation is actually completed, the application will be notified of the IO operation, at which point the user process needs only to process the data, without the need for actual IO read and write operations, Because the true IO read or write operation has been completed 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 model.

(in fact, both blocking and non-blocking can be understood as the concept of synchronization category, for asynchronous, it will not be blocking non-blocking.) For the user process, the data in the user state space of the process is well done directly after receiving the asynchronous notification. ）

First look at the reactor mode, where the reactor mode applies to synchronous I/O scenarios. We take the reading and write operations as an example to see the specific steps in reactor:

Read operations:

1. Application registration Read-ready events and associated event handlers

2. Event separator Waiting for event to occur

3. When a read-ready event occurs, the event separator invokes the event handler registered in the first step

4. The event handler performs the actual read operation first, and then further processes the content based on the read.

A write operation is similar to a read operation, except that the first step registers a write-ready event.

Let's look at the process of read and write operations in Proactor mode:

Read operations:

1. The application initializes an asynchronous read operation and registers the appropriate event handler, at which point the event handler is not concerned with the read-ready event, but instead focuses on the read completion event, which is the key difference from the reactor.

2. Event separator waits for a read operation to complete an 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 application-passed buffer for application operations, the operating system plays an important role), and the read content is put into the buffer that the user This is also a bit different from reactor, where the application needs to pass the buffer. Proactor

4. Event separator, after capturing the read completion event, activates the event handler registered by the application, and the event handler reads the data directly from the buffer, without the need for actual read operations.

Write operations and read operations in Proactor, except that the events of interest are write completion events.

as you can see from the above, the main difference between the reactor and Proactor modes is who the real read and write operations are, and reactor need the application to read or write the data themselves, and in Proactor mode, the application does not need to do the actual read and write process, It only needs to be read or written from the buffer, and the operating system reads the buffer or writes the buffer to the real IO device.

To sum up, synchronous and asynchronous are relative to the application and the kernel of the interaction, synchronization needs to actively ask, and asynchronous when the kernel in the IO event to notify the application, and blocking and non-blocking is only the system calls the system when the function of the implementation of the way.

//////////////////////////////////////////////

When it comes to blocking, let's say I am waiting. I/O wait is unavoidable, then there will be blocking if there is a wait, but note that the blocking we are talking about is that the process that is currently initiating I/O operations is blocked
Synchronous blocking I/O means that when a process calls some system calls or library functions involving I/O operations, such as accept (note that accept is also counted in I/O operations), send (), recv (), and so on, the process pauses and waits for the I/O operation to complete before continuing. This is a simple and
Efficient I/O model, which can be combined with multiple processes to effectively utilize CPU resources, but at the expense of a large amount of memory overhead for multiple processes.

Synchronous blocking process You can't burn porridge by sitting in the water
Synchronous non-blocking is similar to using a process to sit on water and cook porridge.  while (true) {if ... if ...} The benefit is that a process handles multiple I/O requests. The disadvantage is the need for non-stop polling.

The difference is waiting for the data to be ready. Because the data accounted for 80% of the time waiting. The advantage of synchronous non-blocking is that it handles multiple I/O operations simultaneously in one process.

In synchronous blocking I/O, the time that a process actually waits may consist of two parts, one waiting for data to be ready, and the other waiting
According to the replication, for network I/O, the former time may be longer.
In contrast, calls to synchronize non-blocking I/O do not wait for the data to be ready, and if the data is unreadable or not writable, it returns immediately
Tell the process back.

For example, when we use non-blocking recv () to receive network data, if there is no available data in the NIC buffer, the function returns in time, telling the process that there is no data to read. Rather than blocking I/O, this non-blocking I/O combines repeated polling to try
The best thing about data being ready to prevent a process from being blocked is that you can handle multiple I/O operations simultaneously in one process. But it is because of the need for the process to perform multiple polling to see whether the data is ready, which takes a lot of CPU time, making the process in a busy waiting state.

Non-blocking I/O is generally only valid for network I/O, and we simply use O_nonblock in the option settings of the socket, so that the Send () or recv () of the socket is non-blocking.
If the server wants to receive data for more than one TCP connection at the same time, it must rotate the method that receives the data for each socket, such as recv (). Whether or not these sockets have the data to receive, ask again, if most of the socket does not have data to receive, then the process will waste a lot of CPU time to check these sockets, which is obviously not what we want to see.

Synchronous and asynchronous, blocking and non-blocking, some mixed, in fact they are completely not the same thing, and they are decorated with different objects.
Blocking and non-blocking refers to whether the process needs to wait when the data accessed by the process is not ready, simply saying that this corresponds to the implementation difference within the function, that is, if it is not ready to return directly or wait for it to be ready;

Synchronous and asynchronous refers to the mechanism of accessing data, synchronization generally refers to the active request and wait for I/O operations completed in the way, when the data is ready to read and write when the must block (the difference is ready and read and write two phases, synchronous read and write must be blocked), asynchronous refers to the active request data can continue to process other tasks, and then wait The operation is completed, which allows the process to not block when data is read or written. (Wait for "notification")

In most cases, the Web server uses queuing free competition for these requests, using multiple execution streams (multiple processes or multithreading) to fully consume CPU and I/O resources, and reduce any innocent latency, including a number of implementation-specific concurrency policies.
In practical applications, especially Web servers, it is essential to handle a large number of file descriptors at the same time. The advent of multichannel I/O readiness Notifications provides a high-performance solution for a large number of file descriptor readiness checks that allow processes (such as electronic screens that can smell food in restaurants). A way to monitor all file descriptors at the same time, and to quickly get all the ready file descriptors, and then only data access for those file descriptors.
Back to the story of buying noodles, if you not only bought a piece of noodles, but also in a few other snack bars to buy dumplings, porridge, pies, etc., because a friend to go shopping after seeing your noodles also hungry. These things take time to wait for production. In the synchronized non-blocking I/O model, you
Take turns to go to each snack bar to inquire about progress, painful unbearable. Now the introduction of multi-channel I/O ready notification, Snack City management office to the hall installed an electronic screen, after all the food in the snack bar is done, will be displayed on the screen, this is really good news, you just
To have a look at the big screen, you may also be able to stroll around the store at the same time, you can see the big screen not far away.

Multi-Channel ready: 1. Emphasis on multiple routes. 2. Ready only for request data. Not for I/O read/write
Epoll is aimed at such a scene.

Select, Epoll only requires the process (me) to passively receive data ready (noodles) "notifications." Compliant with asynchronous definitions. Do not need to be in the restaurant all the time (synchronous blocking). Or polling (synchronous non-blocking).

Note: 1. The above content is mainly from "Build high-performance Web Site"

2. Understanding of the examples in the book: I (process) supermarket small restaurant (socket) noodles (Request data)