http://www.cppblog.com/kevinlynx/archive/2008/06/06/52356.aspx
@H_502_3@
Proactor和Reactor模式_继续并发系统设计的扫盲
6.6.2008
Kevin Lynx
Proactor和Reactor都是并发编程中的设计模式。在我看来，他们都是用于派发/分离IO操作事件的。这里所谓的@H_502_3@ IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方@H_502_3@ 在于，Proactor用于异步IO，而Reactor用于同步IO。
摘抄一些关键的东西：
"@H_502_3@ Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns @H_502_3@ involve synchronous I/O,whereas the Proactor pattern involves asynchronous I/O.@H_502_3@ "
关于两个模式的大致模型，从以下文字基本可以明白：
"@H_502_3@ An example will help you understand the difference between Reactor and Proactor. We will focus on the read @H_502_3@ 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 ;@H_502_3@ * The event demultiplexor waits for events ;@H_502_3@ * An event comes in and wakes-up the demultiplexor,and the demultiplexor calls the appropriate handler; @H_502_3@ * The event handler performs the actual read operation,handles the data read,declares renewed interest in @H_502_3@ 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 @H_502_3@ case,the handler does not care about I/O readiness events,but is instead registers interest in receiving @H_502_3@ completion events;@H_502_3@ * The event demultiplexor waits until the operation is completed ;@H_502_3@ * While the event demultiplexor waits,the OS executes the read operation in a parallel kernel thread,puts @H_502_3@ data into a user-defined buffer,and notifies the event demultiplexor that the read is complete ;@H_502_3@ * The event demultiplexor calls the appropriate handler; @H_502_3@ * The event handler handles the data from user defined buffer,starts a new asynchronous operation,and returns@H_502_3@ control to the event demultiplexor.
"
可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构@H_502_3@ 上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler。@H_502_3@ 不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示@H_502_3@ IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。
用select模型写个简单的reactor，大致为：
@H_502_3@ 在网上找了份Proactor模式比较正式的文档，其给出了一个总体的UML类图，比较全面：
根据这份图我随便写了个例子代码：
@H_502_3@ Reactor通过某种变形，可以将其改装为Proactor，在某些不支持异步IO的系统上，也可以隐藏底层的实现，利于编写跨平台@H_502_3@ 代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码，在上层，用户提交自己的缓冲区到这一层，@H_502_3@ 这一层检查到设备可操作时，不像原来立即回调handler，而是开始IO操作，然后将操作结果放到用户缓冲区(读)，然后再@H_502_3@ 回调handler。这样，对于上层handler而言，就像是proactor一样。详细技法参见这篇文章。
其实就设计模式而言，我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类，类之间的@H_502_3@ 关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式，只能说模式会给你更多更好的架构方案。
最近在看spserver的代码，看到别人提各种并发系统中的模式，有点眼红，于是才来扫扫盲。知道什么是leader follower模式，@H_502_3@ reactor,proactor，multiplexing，对于心中的那个网络库也越来越清晰。
最近还干了些离谱的事，写了传说中的字节流编码，用模板的方式实现，不但保持了扩展性，还少写很多代码；处于效率考虑，@H_502_3@ 写了个static array容器(其实就是template <typename _Tp,std::size_t size> class static_array { _Tp _con[size])，@H_502_3@ 加了iterator，遵循STL标准，可以结合进STL的各个generic algorithm用，自我感觉不错。基础模块搭建完毕，解析了公司@H_502_3@ 服务器网络模块的消息，我是不是真的打算用自己的网络模块重写我的验证服务器？在另一个给公司写的工具里，因为实在厌恶@H_502_3@ 越来越多的重复代码，索性写了几个宏，还真的做到了代码的自动生成:D。
对优雅代码的追求真的成了种癖好. = =|
posted on 2008-06-06 13:25 Kevin Lynx 阅读(15294) 评论(7) 编辑收藏 引用 所属分类: 网络编程 、模块架构
