注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

还东国的博客

行之苟有恒,久久自芬芳

 
 
 

日志

 
 

(转载)Proactor和Reactor模式_继续并发系统设计的扫盲  

2011-04-20 12:09:43|  分类: 网络服务编程技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
 

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;
}; 
/**//// application
class MyHandler : public handler
{
public:
    void onRead()
     {
    } 
    void onWrite()
     {
    } 
    void onAccept()
     {
    }
}; 


在网上找了份Proactor模式比较正式的文档,其给出了一个总体的UML类图,比较全面:

2011年04月20日 - 还东国 - 还东国的博客

 

根据这份图我随便写了个例子代码:

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。

对优雅代码的追求真的成了种癖好.  = =|

 

  评论这张
 
阅读(908)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017