首页 > 编程知识 正文

事件驱动和多线程,事件驱动型设计

时间:2023-05-05 06:34:11 阅读:142014 作者:2052

在GUI编程中,事件非常常见。 例如,当用户单击界面中的按钮时,将发送“单击”事件,相应地,处理“单击”事件的事件处理器将处理该事件。 因此,

事件驱动,简单地说就是你点击了什么按钮,也就是发生了什么事件,电脑执行了什么操作,也就是调用了什么函数。 当然,事件也不仅仅是用户的操作。 事件驱动的核心当然是事件。 从事件的角度看,事件驱动程序的基本结构由事件收集器、事件发射器和事件处理器组成。 事件收集器负责收集所有事件,包括来自用户的事件(如鼠标、键盘事件)、硬件事件(如时钟事件)和软件事件(如操作系统或APP应用程序本身) 事件发射器将收集器收集的事件分发到目标对象。 事件处理程序负责具体的事件响应工作,往往在实现阶段才完全确定。 对于框架的使用者来说,他们唯一能看到的是事件处理器。 这也是他们关心的内容。

事件驱动编程事件驱动编程通常只使用一个执行过程,CPU之间不是同时的。 处理多任务时,事件驱动编程使用协作处理任务,而不是多线程的抢占式。 事件驱动功能简单易用,只需注册您感兴趣的事件并为回调设计逻辑即可。 在调用期间,事件循环(Event Loop )等待事件发生并调用处理器。 事件处理器不是抢占式处理器,处理器的生命周期通常很短。

事件驱动编程的优点是,在大多数APP场景中,事件编程很好,而且是多线程编程。 与多线程编程相比,事件驱动编程相对容易且复杂度低,是开发人员乐于接受的。 的大多数GUI框架都是使用事件驱动对体系结构进行编程的。 每个事件都有一个与之相关联的处理器。 这些事件通常是单击按钮或选择菜单。 处理器r实现具体的操作逻辑。 事件驱动常用于I/O框架,可以很好地实现I/O复用。 许多高性能I/O框架(如Netty、Mina和Node.js )使用事件驱动模型。 很容易调试。 时间依赖只与事件有关,而不是内部调度。 问题容易显现。 如果事件驱动编程的不利处理器占用时间太长,则会阻止APP发送响应。 由于处理器必须返回,因此无法在时间上保持本地状态。 在单CPU环境中,速度通常比多线程编程快。 因为没有锁定的元素,所以没有线程切换的损失。 因为CPU不是同时的,所以这样不适合一些科学计算的应用。 事件循环器(Event Loop )的安装事件循环器(Event Loop )是用于等待和发送消息和事件的程序结构。 事件驱动编程的代码核心是事件循环器,在Linux上推荐epoll实现,在没有其他epoll的系统上可以使用kqueue/ports/poll/select实现。

下图为事件循环器官的动作示例图。 事件循环器不断受理来自客户端(客户端)的请求,事件循环器将请求传递到登记了某种事件的工作线程(working lead )进行处理。

[外部链图像导出失败。 源站可能有防盗链机制。 建议保存图像并直接上传(img-fuDJ6NSF-1611152553859 ) https://community file-drcn.op.hi cloud.com/file server/getfile/getfile cmtybs 00000000000042413002.20200114100830.8845695920647169700097365336021012022141233602800280000:0 e 2751 d 8419276 d2.2

根据实现方式的不同,网络编程中基于事件驱动的主要有Reactor和Proactor两种设计模式。

Reactor首先回想一下一般的函数调用的结构。

程序调用函数-函数运行并等待程序-函数将结果控制权返回给程序-程序继续处理与普通函数调用不同。 APP应用程序并不主动调用API来完成处理,相反,APP应用程序必须提供相应的接口并向Reactor注册。 发生适当的事件时,Reactor会主动调用APP注册的接口。 这些接口也称为回调函数。

用“好莱坞原则”来表达Reactor是不合适的。 请不要打电话。 打电话通知。

举个例子,应聘某xx公司,面试结束后。

“普通函数调用机制”公司的HR懒惰,不记得你的联系方式。 那么,我们该怎么办? 面试结束后只能自己打电话问结果。 是否被录用,还是被拒绝; “Reactor”公司的人力资源会记录下你的联系方式,结果出来后会积极打电话通知你。 是否被录用,还是被拒绝; 你不需要自己打电话问结果。 实际上不行。 因为没有HR的联系方式。 [外部链图像导出失败。 源站可能有防盗链机制。 建议保存图片并直接上传。 (img-KEuA0MDZ-1611152553861 ) https://community file-drcn.op.hi cloud.com/file server/getfile/cmtybbs/com 0000000000042413002.20200114100933.937335887164670352487803360210120214123360280033608 ca 0719 c 032939438 a 753 ee

回复

or模式的优点

Reactor模式是编写高性能网络服务器的必备技术之一,它具有如下的优点:

1)响应快,不必为单个同步时间所阻塞,虽然Reactor本身依然是同步的;

2)编程相对简单,可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销;

3)可扩展性,可以方便的通过增加Reactor实例个数来充分利用CPU资源;

4)可复用性,Reactor框架本身与具体事件处理逻辑无关,具有很高的复用性;

Reactor模式框架

使用Reactor模型,必备的几个组件:事件源、Reactor框架、事件多路复用机制和事件处理程序,先来看看Reactor模型的整体框架,接下来再对每个组件做逐一说明。

1)事件源:Linux上是文件描述符,Windows上就是Socket或者Handle了,这里统一称为“句柄集”;程序在指定的句柄上注册关心的事件,比如I/O事件。

2)事件多路复用机制:由操作系统提供的I/O多路复用机制,比如select和epoll。程序首先将其关心的句柄(事件源)及其事件注册到多路复用机制上。当有事件到达时,事件多路复用机制会发出通知“在已经注册的句柄集中,一个或多个句柄的事件已经就绪”。程序收到通知后,就可以在非阻塞的情况下对事件进行处理了。

3) Reactor。是事件管理的接口,内部使用事件多路复用机制注册、注销事件;并运行事件循环,当有事件进入“就绪”状态时,调用注册事件的回调函数处理事件。

4)事件处理程序。事件处理程序提供了一组接口,每个接口对应了一种类型的事件,供Reactor在相应的事件发生时调用,执行相应的事件处理。通常它会绑定一个有效的句柄。

使用Reactor模式后,事件控制流是什么样子呢?可以参见下面的序列图。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gTUJVLrK-1611152553863)(https://communityfile-drcn.op.hicloud.com/FileServer/getFile/cmtybbs/042/413/002/0000000000042413002.20200114100945.37106645656333954632891663459657:20210120221412:2800:EBB8441B2BE20AB8EE8B594648D03EA1018AD318F6CA741A8E8592F021C46308.png)]

我们分别以读操作和写操作为例来看看Reactor中的具体步骤:

应用程序注册读就绪事件和相关联的事件处理器;

事件分离器等待事件的发生;

当发生读就绪事件的时候,事件分离器调用第一步注册的事件处理器;

事件处理器首先执行实际的读取操作,然后根据读取到的内容进行进一步的处理。

写入操作类似于读取操作,只不过第一步注册的是写就绪事件。

Proactor

我们来看看Proactor模式中读取操作和写入操作的过程:

应用程序初始化一个异步读取操作,然后注册相应的事件处理器,此时事件处理器不关注读取就绪事件,而是关注读取完成事件,这是区别于Reactor的关键。

事件分离器等待读取操作完成事件。

在事件分离器等待读取操作完成的时候,操作系统调用内核线程完成读取操作(异步I/O都是操作系统负责将数据读写到应用传递进来的缓冲区供应用程序操作),并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点。

事件分离器捕获到读取完成事件后,激活应用程序注册的事件处理器,事件处理器直接从缓存区读取数据,而不需要进行实际的读取操作。

Proactor中写入操作和读取操作,只不过感兴趣的事件是写入完成事件。

从上面可以看出,Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的,Reactor中需要应用程序自己读取或者写入数据,而Proactor模式中,应用程序不需要进行实际的读写过程,它只需要从缓存区读取或者写入即可,操作系统会读取缓存区或者写入缓存区到真正的I/O设备。

参考引用

原文同步至:https://developer.huawei.com/consumer/cn/forum/topic/0201143789935040160?fid=23

《Netty原理解析与开发实战》见:http://product.dangdang.com/29180429.html 或:https://item.jd.com/13072504.html

《分布式系统常用技术及案例分析(第二版)》

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。