Two efficient server design patterns: Reactor and Proactor

IO model

"Unix Network Programming" (12) Five I/O models are mentioned in the five I/O models.
We all know that for the consideration of OS security, the process cannot directly operate the I/O device. It must pass the System calls request the kernel to assist in completing I/O operations, and the kernel maintains a buffer for each I/O device. As shown below:

  write picture description here

  The entire request process is as follows: The user process initiates the request. After the kernel receives the request, it obtains data from the I/O device into the buffer, and then copies the data in the buffer to the address space of the user process. After the user process obtains the data, Respond to the client.

  During the entire request process, it takes time to input data to the buffer, and it also takes time to copy data from the buffer to the process. Therefore, according to the different waiting methods during these two periods, I/O actions can be divided into the following five modes:

  (1) 阻塞I/O (Blocking I/O)

  (2) Non-Blocking I/O (Non-Blocking I/O)

  (3) For I / O Recovery (I / O Multiplexing)

  (4) Signal Driven I/O (Signal Driven I/O)

  (5)
The first four kinds of asynchronous I/O (Asynchrnous I/O) are synchronous, and only the last one is asynchronous IO. As we all know, select, poll, and epoll are all I/O multiplexing, which will also block the process. But different from blocking I/O, the two stages of I/O execution [waiting for data, receiving data] are blocked in the user process, but the two stages are independent, and in a complete I/O operation , the user process has initiated two system calls, and the CPU can do other tasks during the time. They can block multiple I/O operations at the same time. Moreover, the I/O functions of multiple read operations and multiple write operations can be detected at the same time, and the I/O operation functions are not actually called until data is readable or writable.

Difference between Reactor and Proactor

In the Reactor mode, the event separator waits for an event or a state that can be applied or an operation to occur (for example, the file descriptor can be read and written, or the socket can be read and written), and the event separator will pass the event to the pre-registered. Handler (event handler or callback function), which does the actual read and write operations.
In the Proactor mode, the event handler (or initiated by the event separator) directly initiates an asynchronous read and write operation (equivalent to a request), and the actual work is done by the operating system. When initiating, the parameters that need to be provided include the buffer area used to store the read data, the size of the read data, or the buffer area used to store the outgoing data, and the callback function after the request is completed. The event separator knows the request, it silently waits for the completion of the request, and then forwards the completion event to the corresponding event handler or callback.

The difference between the two can be seen: Reactor notifies the pre-registered event when the event occurs (read and write is completed by the handler function); Proactor performs asynchronous I/O when the event occurs (read and write is completed by the OS), waiting for IO The handler is dispatched for processing when the event separator is completed.

For example, it will help to understand the difference between Reactor and Proactor, taking read operation as an example (class operation is similar).
Implement read in Reactor (synchronous):
- Register read ready event and corresponding event handler
- Event separator waits for event
- Event arrives, activates the separator, and the separator calls the handler corresponding to the event.
- The event handler completes the actual read operation, processes the read data, registers a new event, and returns control.
Read in Proactor (asynchronous):
- The processor initiates an asynchronous read operation (Note: the operating system must support asynchronous IO). In this case, the processor ignores the IO ready event, it focuses on the completion event.
- Event separator waiting for operation completion event
- During the separator waiting process, the operating system uses parallel kernel threads to perform the actual read operation, stores the result data in the user-defined buffer, and finally informs the event separator that the read operation is completed.
- The event separator calls the handler.
- The event handler processes the data in the user-defined buffer, then starts a new asynchronous operation and returns control to the event separator.

to be continued---

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326028407&siteId=291194637