Reactor and Proactor modes for high performance IO design

In the high-performance I/O design, there are two well-known modes reactor and Proactor modes, where reactor mode is used for synchronous I/O, and Proactor is used for asynchronous I/O operations.

Before comparing 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 operation and waiting or polling to see if the IO operation is ready, and asynchronous refers to the user process triggered IO operation will start to do their own things, and when the IO operation has been completed when the IO will be completed notification. while blocking and non-blocking is for the process at the time of access to data, according to the readiness of the IO operation to take a different way , White is a read or write operation function Implementation mode, blocking mode read or write function will wait, not blocking mode, The read or write function returns a status value immediately.

Generally speaking I/O models 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 initiating an IO operation, and the user process will not run until the IO operation is actually completed. Java's traditional IO model belongs to this approach.

synchronous non-blocking IO:

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

Asynchronous blocking IO:

In this way, after the application initiates an IO operation, does not wait for the kernel IO operation to complete, and so on after the kernel completes the IO operation notifies the application, this is actually the synchronization and the asynchronous most crucial difference, the synchronization must wait or the initiative to ask whether the IO completes, then why say is 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 to multiple file handles at the same time, thus 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 actual completion of the IO operation, the application will get the IO operation to complete the notification, at this time the user process only need to process the data, do not need to do the actual IO read and write operations, Because the actual 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, we look back at the reactor mode and the Proactor mode.

First look at the reactor mode, the reactor mode applied to the synchronous I/O scenario. Let's take a read operation and write operation as an example to see the specific steps in reactor:

Read Operation :

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

2. Event separators wait for events to occur

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

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

A write operation is similar to a read operation, except that the first step is to register a 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 appropriate event handler, at which point the event handler does not focus on the read-ready event, but instead focuses on the read completion event, which is the key to distinguish it from the reactor.

2. Event Splitter waits for read operation completion event

3. When the event splitter waits for the read operation to complete, the operating system invokes the kernel thread to complete the read operation and puts the contents of the read into the buffer passed by the user. This is also a bit different from reactor, where the application needs to pass the buffer proactor.

4. After the event splitter captures 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 events of interest are write completion events.

As can be seen from the above, the main difference between the reactor and Proactor modes is that the real read and write operations are done by someone, and the reactor requires the application to read or write the data itself, whereas in Proactor mode, the application does not need to perform the actual read/write process. It only needs to read or write 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 is relative to the application and the core of the interaction, synchronization needs to proactively ask, and asynchronous when the kernel at the time of 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.

Source Address: http://xmuzyq.iteye.com/blog/783218

In general, the I/O multiplexing mechanism requires event demultiplexor [1, 3]. The role of event sharing, will be those who read and write event source distributed to the processing of read and write events, like the delivery of a courier downstairs shouting: Who sent something, come and take it. The developer needs to register the event of interest at the beginning, and provide the appropriate handler (event handlers), or a callback function; The event-sharing device distributes the requested events to these handler or callback functions when appropriate.

Two modes involving event-sharing are called: Reactor and Proactor [1]. The reactor mode is based on synchronous I/O, while the proactor mode is associated with asynchronous I/O. In the reactor mode, the event splitter waits for an event or the state of the application or operation to occur (such as the file descriptor can read or write, or the socket can read and write), the event splitter will pass this event to the pre-registered event handler function or callback function, the latter to do the actual read and write operations.

In Proactor mode, an event handler (or a generation initiated by an event splitter) directly initiates an asynchronous read-write operation (equivalent to a request), and the actual work is done by the operating system. At the time of initiation, the parameters to be provided include the buffers used to hold the data read, the size of the data being read, or the buffers used to store the outgoing data, and the callback function after the request. The event Splitter learns the request, silently waiting for the request to complete, and then forwards the completion event to the appropriate event handler or callback. [1] For example, an event processor on Windows posted an asynchronous IO operation (known as overlapped technology), event Splitter, and so on IoCompletion event completion. The typical implementation of this asynchronous pattern is based on the underlying asynchronous API of the operating system, so we can call it "system-level" or "really" asynchronous because the specific read and write is handled by the operating system.

Give another example to better understand the difference between the two modes of reactor and Proactor. Here we only focus on the read operation, because the write operation is similar. Here's what reactor does: an event handler claims that it is interested in reading events on a socket; The event separator is waiting for the event to occur; When an event occurs, the event splitter is awakened, which notifies the previous event handler; The event handler receives the message and then goes to the socket to read the data. If needed, it again claims to be interested in the read event on the socket, repeating the above steps;

Let's take a look at how the true meaning of asynchronous mode Proactor is done: The event handler sends a write operation directly (of course, the operating system must support this asynchronous operation). At this point, the event handler simply does not care about reading the event, it just sends the request, it is the completion of this write operation event. This handler is very drag, send a command, regardless of the specific things, just waiting for someone else (System) to help him fix the time to give him back a message. The event splitter waits for the completion of this read event (compared to the reactor); When the event separator silently waiting to complete the matter, the operating system has started to work on the side, it reads data from the target, into the user-provided buffer, and finally notify the event separator, this thing I finished; Event-sharing notification before the event handler: the things you commanded were settled; The event handler will then find that the data he wants to read is already in the cache that he has provided, and what to do with it. If necessary, the event handler initiates another write operation as before, as in the previous steps.