加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

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

发布时间:2020-12-15 05:29:58 所属栏目:百科 来源:网络整理
导读:Proactor和Reactor模式_继续并发系统设计的扫盲 6.6.2008 Kevin Lynx Proactor和Reactor都是并发编程中的设计模式。在我看来,他们都是用于派发/分离IO操作事件的。这里所谓的 IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层

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:
virtualvoidonRead()=0;
virtualvoidonWrite()=0;
virtualvoidonAccept()=0;
}
;

class dispatch
{
public:
voidpoll()
{
//addfdintheset.
//
//polleveryfd
intc=select(0,&read_fd,&write_fd,0,0);
if(c>0)
{
foreachfdintheread_fd_set
{iffdcanread
_handler
->onRead();
iffdcanaccept
_handler
->onAccept();
}


foreachfdinthewrite_fd_set
{
iffdcanwrite
_handler
->onWrite();
}

}

}


voidsetHandler(handler*_h)
{
_handler
=_h;
}


private:
handler
*_handler;
}
;

///application
class MyHandler: public handler
{
public:
voidonRead()
{
}


voidonWrite()
{
}


voidonAccept()
{
}

}
;


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

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

class AsyIOProcessor
{
public:
voiddo_read()
{
//sendreadoperationtoOS
//readiofinished.anddispatchnotification
_proactor->dispatch_read();
}


private:
Proactor
*_proactor;
}
;

class Proactor
{
public:
voiddispatch_read()
{
_handlerMgr
->onRead();
}


private:
HandlerManager
*_handlerMgr;
}
;

class HandlerManager
{
public:
typedefstd::list
<Handler*>HandlerList;

public:
voidonRead()
{
//notifyallthehandlers.
std::for_each(_handlers.begin(),_handlers.end(),onRead);
}


private:
HandlerList
*_handlers;
}
;

class Handler
{
public:
virtualvoidonRead()=0;
}
;

// applicationlevelhandler.
class MyHandler: public Handler
{
public:
voidonRead()
{
//
}

}
;


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 阅读(15618) 评论(7) 编辑收藏 引用 所属分类: 网络编程 、模块架构

评论

#re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 15:13关中刀客

模式是个好东西,但不是绝对的好东西,有时也不是很必要使用proactor回复更多评论

#re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 15:40Kevin 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:19Kevin 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建模的方法。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读