为什么`boost :: asio :: deadline_timer`为每个`deadline_timer`对象分配一个`timer_queue`实例？

Question

我正在研究boost::asio::deadline_timer的实现，基于boost 1.52。

如the article on highscore所述，它分为三部分实施：

• deadline_timer，即i / o对象
• deadline_timer_service，服务
• detail::deadline_timer_service，服务实施

将有一个deadline_timer_service个实例服务于许多deadline_timer个对象。为每个detail::deadline_timer_service对象创建deadline_timer的实例。此外，定时器由调度程序调度，调度程序通常是一个反应堆（在大多数情况下，在Linux上为epoll_reactor）。

timer_queue_中有timer_queue个detail::deadline_timer_service成员，它是一个存储预定计时器的堆。这意味着每个timer_queue对象将有一个deadline_timer实例。 timer_queue可以将多个add_timer_queue()个对象添加到调度程序中，它们由类timer_queue_set管理。

我的问题是，为什么asio创建多个队列来处理计时器？如果我们在调度程序中有一个所有计时器可以共享的计时器队列实例，那么有什么缺点？

Answer 1

我再次阅读代码，发现我的错误。实际关系如下：

• basic_deadline_timer是i / o对象类型，每个deadline_timer都有一个实例;
• deadline_timer_service是服务类型，每个io_service一个，由basic_io_object的构造函数检索;
• detail::deadline_timer_service是服务实现类型，每个服务一个，每个io_serive只有一个。它被定义为deadline_timer_service;
的数据成员
• detail::deadline_timer_service::implementation_type：计时器的实现类型，每deadline_timer一个。

由于timer_queue_是detail::deadline_timer_service的成员，因此每io_service也是一个成员。对我来说现在看起来很合理。

高分数链接似乎已将服务实现类型和计时器实现类型合并为一个，这有点误导。