Proactor and reactor in Aces

Proactor and reactor in Aces

Ace_select_reactor is the default reactor implementation that is used by all platforms except Windows and will eventually wait with the Select () system function on those systems. Ace_wfmo_reactor on Windows is the default reactor implementation. The implementation does not use the Select () multiplexer, but instead uses the WaitForMultipleObjects (). When using Ace_wfmo_reactor, some tradeoffs are needed: Ace_wfmo_reactor can only register 62 handles. The underlying waitformutipleobejcts () function is 64, the ACE uses two internally, the I/O type, and ace_wfmo_reactor only supports Handler_input (), handler_ on the socket handle. I/O callbacks for Output () and handler_exception (); Ace_wfmo_reactor can react to a handle, such as a file change notification handle and an event handle, as long as it can be used with waitformultipleobjects ().

Ace_win32_proactor is an Ace_proactor implementation on Windows that uses I/O to complete multi-port completion event detection. When an asynchronous operation factory is initialized (such as Ace_asynch_read_stream or Ace_aysnch_write_stream), the I/O handle is associated with the I/O completion port of Proactor. In this implementation, the GetQueuedCompletionStatus () function of Windows is used to perform a time loop. Multiple threads can perform ace_win32_proactor time loops simultaneously. The ACE Proactor implementation on the POSIX system provides a variety of mechanisms for initiating I/O operations and checking their completion. The POSIX asynchronous I/O mechanism encapsulated by ACE supports the read () and write () operations, but does not support operations related to TCP/IP connections, in order to support Ace_asynch_acceptro and Ace_asynch_connector functions, ACE uses a separate thread to perform connection-related operations. Therefore, when using the Proactor framework on a POSIX platform, the program will run multiple threads. The internal mechanism of the ACE allows you to eliminate time processing in multiple threads, so you don't need to add any special lock or sync.

First of all want to write the network processing program, then to understand the limitations of each step is what, in short, there must be read (write) data, and processing data two parts, then this two parts have what characteristics? The read data is primarily I/O operations, while a single I/O operation may have to wait, and I/O operations are less CPU intensive, and most importantly I/O speed is similar to the speed of the CPU. A thread can handle many I/O operations on a wide range of paths, activating the separator when I/O completes, and invoking the event handler by the splitter. Make a hypothesis, there may be 1000 data requests at the same time, if not reactor, then may open 1000 threads or processes to service, this time the first thread between the switching and locking overhead is very large, and if the use of reactor, may use only one read thread, Take turns to read these 1000 requests, and then when one of the reads is complete, the splitter is activated, the splitter invokes the event handler, so that if the system processes the data quickly, then the simultaneous presence of threads may be minimal, reducing the system's thread creation switching and destruction.

Remember before the server program, there is a read request thread pool, a processing thread pool, so that in fact, and the principle of reactor mode, the reading and processing separation, and then use a message queue to complete the reading and processing of communication, which will use the lock, The design of the lock is not only complex but also systematic overhead. But reactor does not use a lock, only a buffer to tell the dispatcher, when the end of the read callback processing handler. (In the ACE is not very sure of the lock implementation) and, just like that design interaction is more troublesome, if reading is relatively simple, but read if it would be more troublesome to send.

Here are some other blog posts summarizing reactor and Proactor's reading process: Realizing reading in reactor:
-Register read-ready events and corresponding event handlers
-Event Splitter Wait event
-the event arrives, activates the splitter, and the splitter invokes the event corresponding to the processor.

-the event handler completes the actual read operation, processes the read data, registers the new event, and then returns control. Implement read in Proactor:
-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, and it focuses on the completion event.
-Event splitter waits for Operation completion event
-During the separator wait, the operating system takes advantage of the parallel kernel thread to perform the actual read operation and stores the resulting data in the user-defined buffer, and finally notifies the event splitter that the read operation is complete.
-The event splitter calls the processor.
-the event handler handles the data in the user-defined buffer, then initiates a new asynchronous operation and returns control to the event splitter


Simple summary of the same points and different points:
Same point
1) all have event demutiplexer (why is it called Event multiplexer?). Mainly from its function, it can separate the I/O time of the event source and distribute to the corresponding Read/write event processing area (the event Handler), which is responsible for callback Handler.
2) Read (write) data, and processing after the end of the two process is divided, which is also the focus of reactor, without a thread to complete from the read data until the end of processing, read the data thread and processing thread is two different threads. This has the advantage that reading the data can be time-consuming, and that a thread can handle the I/O processing of a lot of the data as the bottleneck is actually the system's I/O.

Different points:
1) Proactor is the callback handler when I/O operation is complete, and reactor is called handler when I/O can read or write.
2) Proactor reads and writes are done using the operating system to support asynchronous I/O Read and write operations, while the reactor I/O operations are done by the user.
3) reactor is synchronous, requires the user to perform the I/O operation and then wait for the I/O operation to complete, perform certain operations, Proactor is asynchronous, after initiating I/O operation to the operating system, only concerned about the IO completion event. There's a small misunderstanding here at first,


In fact, reactor and Proactor in waiting for I/O event arrival can be understood as asynchronous, may be used to select () the underlying function, when the port can operate by the operating system asynchronous notification, this time reactor receive notification, call handler. However, Proactor is not satisfied when the port is operational, it needs to be notified asynchronously after I/O operation is complete, so that Proactor is equivalent to two-layer asynchronous operation, whereas reactor and Proactor "Async" refer to the back I/O operation.

The user-defined action in the reactor framework is called before the actual operation. For example, if you define the operation to write data to a socket, then when the socket can receive the data, your operation will be called, and the user-defined action in the Proactor framework is called after the actual operation. For example, if you define an operation to display the data that is read from the socket, your operation will be called when the read operation is completed. ”

Reference:Http://www.cnblogs.com/dawen/archive/2011/05/18/2050358.html
Http://name5566.com/4175.html