Proactor和Reactor模式_继续并发系统设计的扫盲
时间：2010-06-25 来源：jiqiubo
Proactor和Reactor模式_继续并发系统设计的扫盲
6.6.2008 Kevin Lynx Proactor和Reactor都是并发编程中的设计模式。在我看来，他们都是用于派发/分离IO操作事件的。这里所谓的IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于，Proactor用于异步IO，而Reactor用于同步IO。 摘抄一些关键的东西： "
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns
involve synchronous I/O, whereas the Proactor pattern involves asynchronous 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. " 可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构
上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler。
不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示
IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。 用select模型写个简单的reactor，大致为：
///
class handler{
public: virtual void onRead() = 0; virtual void onWrite() = 0; virtual void onAccept() = 0;
}; class dispatch{public: void poll()
{ // add fd in the set. //
// poll every fd int c = select( 0, &read_fd, &write_fd, 0, 0 ); if( c > 0 ) { for each fd in the read_fd_set { if fd can read _handler->onRead(); if fd can accept _handler->onAccept();
} for each fd in the write_fd_set { if fd can write _handler->onWrite(); } } } void setHandler( handler *_h ) { _handler = _h; } private: handler *_handler;}; /// applicationclass MyHandler : public handler{public: void onRead() { } void onWrite() { } void onAccept() { }};
在网上找了份Proactor模式比较正式的文档，其给出了一个总体的UML类图，比较全面：
根据这份图我随便写了个例子代码：
class AsyIOProcessor{public: void do_read() { //send read operation to OS // read io finished.and dispatch notification _proactor->dispatch_read(); } private: Proactor *_proactor;}; class Proactor{public: void dispatch_read() { _handlerMgr->onRead(); } private: HandlerManager *_handlerMgr;}; class HandlerManager{public: typedef std::list<Handler*> HandlerList; public: void onRead() { // notify all the handlers. std::for_each( _handlers.begin(), _handlers.end(), onRead ); } private: HandlerList *_handlers;}; class Handler{public: virtual void onRead() = 0;}; // application level handler.class MyHandler : public Handler{public: void onRead() { // }};
Reactor通过某种变形，可以将其改装为Proactor，在某些不支持异步IO的系统上，也可以隐藏底层的实现，利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码，在上层，用户提交自己的缓冲区到这一层，
这一层检查到设备可操作时，不像原来立即回调handler，而是开始IO操作，然后将操作结果放到用户缓冲区(读)，然后再
回调handler。这样，对于上层handler而言，就像是proactor一样。详细技法参见这篇文章。 其实就设计模式而言，我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类，类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式，只能说模式会给你更多更好的架构方案。 最近在看spserver的代码，看到别人提各种并发系统中的模式，有点眼红，于是才来扫扫盲。知道什么是leader follower模式，
reactor, proactor，multiplexing，对于心中的那个网络库也越来越清晰。 最近还干了些离谱的事，写了传说中的字节流编码，用模板的方式实现，不但保持了扩展性，还少写很多代码；处于效率考虑，
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size])，
加了iterator，遵循STL标准，可以结合进STL的各个generic algorithm用，自我感觉不错。基础模块搭建完毕，解析了公司
服务器网络模块的消息，我是不是真的打算用自己的网络模块重写我的验证服务器？在另一个给公司写的工具里，因为实在厌恶
越来越多的重复代码，索性写了几个宏，还真的做到了代码的自动生成:D。 对优雅代码的追求真的成了种癖好. = =| posted on 2008-06-06 13:25 Kevin Lynx 阅读(5309) 评论(7) 编辑 收藏 引用 所属分类: 网络编程 、模块架构
评论
# re: Proactor和Reactor模式_继续并发系统设计的扫盲 2008-06-06 15:13 关中刀客
模式是个好东西，但不是绝对的好东西,有时也不是很必要使用proactor 回复 更多评论# re: Proactor和Reactor模式_继续并发系统设计的扫盲 2008-06-06 15:40 Kevin Lynx
@关中刀客传说哥们和我同年同月差一天就同日生(我10号:d)
还有，一直想看下你的cobra是个什么东西 回复 更多评论
# re: Proactor和Reactor模式_继续并发系统设计的扫盲 2008-06-06 16:43 关中刀客
To Kevin Lynx兄：呵呵，有缘有缘，我的cobra_win是一个网络通讯库，主要是针对iocp，采用异步多线程，底层目前已经有了自己的一套内存管理策略，比较完善的日志模快，定时器模块等等，感觉对于底层来说，已经相对的完善了，现在需要做的就是多多的改进和修正很多东西。呵呵，以后可以多多的交流~ 回复 更多评论
# re: Proactor和Reactor模式_继续并发系统设计的扫盲 2008-06-06 17:19 Kevin Lynx
@关中刀客难道不开源？不知道能否分享下代码。
我之前在google,baidu都搜索过你这个东西，没有发现类似googlecode之类的项目地址。。 回复 更多评论
# re: Proactor和Reactor模式_继续并发系统设计的扫盲 2008-06-11 14:15 胡章优
写的很不错这两个模式在服务器开发中是应用的最多的算是
另外一点开发的重点在集群管理上面
刀客的东西可能想商业化，并没有开源的打算 回复 更多评论
# re: Proactor和Reactor模式_继续并发系统设计的扫盲[未登录] 2008-06-12 19:25 杨粼波
IOCP就是Proactor实现的系统级的事件分离器。leader follower模式，是一种并发模式，也可以说是一种策略。
这些都可以在ACE的那两本网络编程的书里面看到讲解。
我最近一直看这书，一边写自己的网络库。之前写的不满意，现在重新写一个。尝试先用UML建模的方法
相关阅读 更多 +
