c++ - 要不要使用事件对象？

Question

据我所知，主动对象设计模式是将一个(私有(private)/专用)线程生命周期与一个对象绑定(bind)在一起，并使其在独立数据上工作。从我读到的一些文档来看，这种范式的演变有两个原因，首先，管理原始线程会很痛苦，其次更多的线程争用共享资源不能很好地使用互斥锁和锁进行扩展。虽然我同意第一个原因，但我并不完全理解第二个原因。使对象处于事件状态只会使对象独立，但诸如争用锁/互斥锁之类的问题仍然存在(因为我们仍然有共享队列/缓冲区)，对象只是将共享责任委托(delegate)给了消息队列。正如我所见，这种设计模式的唯一优点是我必须在共享对象上执行长时间异步任务的情况(现在我只是将消息传递到共享队列，线程不再需要在互斥锁上长时间阻塞/锁，但他们仍然会阻塞并争夺发布消息/任务)。除了这种情况，有人可以告诉更多这种设计模式将具有其他优势的场景。

我的第二个问题是(我刚刚开始研究设计模式)，事件对象、 react 器和前摄器设计模式之间的概念区别是什么。您如何决定哪种设计模式更有效并且更适合您的要求。如果有人可以展示某些示例来展示这三种设计模式的行为方式以及哪一种在不同场景中具有比较优势/劣势，那就太好了。

我有点困惑，因为我使用了事件对象(使用共享线程安全缓冲区)和 boost::asio(Proactor) 都做了类似的异步操作，我想知道是否有人有更多对处理问题时不同模式的适用性的见解。

Answer 1

ACE website在 Active Object 上有一些非常好的论文, Proactor zh Reactor设计模式。他们的意图的简短摘要:

Active Object 设计模式解耦方法执行从方法调用来增强并发性和简化对驻留在其中的对象的同步访问自己的控制线程。也称为:并发对象、Actor。

Proactor 模式支持多路分解和调度多个事件处理程序，由完成触发的异步事件。这种模式在 Boost.Asio 中大量使用。

Reactor 设计模式处理交付的服务请求同时向一个或多个客户提出申请。每项服务在一个应用程序中可能包含多个方法，并由一个单独的事件处理程序，负责调度特定服务要求。也称为:调度程序、通知程序。