Comparing Two High-Performance I/O Design Patterns

by Alexander Libman with Vladimir Gilbourd

Reactor and Proactor: two I/O multiplexing approaches

In general, I/O multiplexing mechanisms rely on an event demultiplexor，an object that dispatches I/O events from a limited
number of sources to the appropriate read/write event handlers.

The developer registers interest in specific
events and provides event handlers, or callbacks. The event demultiplexor delivers the requested events to the event handlers.

Two
patterns that involve event demultiplexors are called Reactor and Proactor 。

The
Reactor patterns involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.

In Reactor, the event demultiplexor waits for events that indicate when a file descriptor or
socket is ready for a read or write operation.

The demultiplexor passes this event to the
appropriate handler, which is responsible for performing the actual read or write.

In
the Proactor pattern, by contrast, the handler—or the event demultiplexor on behalf of the handler—initiates asynchronous read and write operations.The
I/O operation itself is performed by the operating system (OS). The parameters passed to the OS include the addresses of user-defined data buffers from which the OS gets data to write, or to which the OS puts data read.The
event demultiplexor waits for events that indicate the completion of the I/O operation, and forwards those events to the appropriate handlers.

For example, on Windows a handler could initiate async I/O (overlapped in Microsoft terminology)
operations, and the event demultiplexor could wait for IOCompletion events 。The implementation of this classic asynchronous pattern is based on an asynchronous OS-level API, and we will call this implementation
the "system-level" or "true" async, because the application fully relies on the OS to execute actual I/O.

An
example will help you understand the difference between Reactor and Proactor. We will focus on the read operation here, as the write implementation is similar. Here‘s a read in Reactor:

• An event handler declares interest in I/O events that indicate readiness for read on a particular socket
• The event demultiplexor waits for events
• An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler
• The event handler performs the actual read operation, handles the data read, declares renewed interest in I/O events, and returns control to the dispatcher

By comparison, here is a read operation in Proactor (true async):

• A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this case, the handler does not care about I/O readiness events, but is instead registers interest in receiving completion events.
• The event demultiplexor waits until the operation is completed
• While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts data into a user-defined buffer, and notifies the event demultiplexor that the read is complete
• The event demultiplexor calls the appropriate handler;
• The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns control to the event demultiplexor.

版权声明：本文为博主原创文章，未经博主允许不得转载。