无限循环vs boost :: asio :: deadline_timer C++性能

我开发了一个处理来自客户端的许多连接的服务器应用程序。服务器定期向每个客户端发送消息（例如：每1秒），检查客户端的到期时间（每个客户端必须在连接时间达到预定值时强制与服务器断开连接）以及其他一些定时器任务。我认为2个解决方案：无限循环vs boost :: asio :: deadline_timer C++性能

使用，而（真）{的foreach客户{检查时间}}
为每一个客户，delcare一个deadline_timer并呼吁async_wait每个任务，所以这将产生很多deadline_timer实例

哪种解决方案更适合性能？一般来说，我应该使用无限循环还是声明多个计时器实例？还有一个，你能解释OS如何管理deadline_timer吗？

来源

2015-08-25 Ikarus

问：哪种解决方案更适合性能？

无限循环通常不好。在具有线程相关性的CPU饱和工作人员中发现异常（但在此似乎不适用）。

问：一般情况下，我应该使用无限循环

没有

问：或声明多计时器实例？

或者只是

std::vector<boost::shared_ptr<asio::deadline_timer> > m_timers;

或类似:)

问：还有一，你能解释操作系统如何管理deadlien_timer？

定时器在引擎盖下使用特定于平台的内核事件。意思是，在实践中，如果你有例如10个任务在不同的定时器上都被阻塞，内核会保持进程处于睡眠状态（根本不运行），直到第一个过期。

到目前为止，内核级同步基元通常是非CPU绑定工作负载的最快方式。

来源

2015-08-25 06:16:52 sehe

，则需要创建deadline_timer实例的数量巨大。 deadline_timer实例的数量是否有限制？ – Ikarus

这将被实现定义。如果它的的确确是“巨额”（见的Calvins回答），确实考虑“标记和清除”的方式，交易准确性资源使用情况和可能_average_（！）的IO速率 – sehe

您是否要求每个客户端在完全（或接近）一秒时间内超时？

我会做第三条道路：

while (true) { 
    if (elapsed_one_second()) { 
    for each client { 
     client->check_timeout(); 
    } 
}

或者，如果你有事件队列，你做一个定时器触发所有客户端的检查。

编辑：如果你有大量的定时器，你也可以考虑实现一个增量队列，并为最早的事件使用一次性定时器。

来源

2015-08-25 04:14:05

我想要的时间是相当准确的，所以这个解决方案不适合 – Ikarus

在这种情况下，你可以做一个三角形队列，并使用一个定时器，你对复杂的完全控制。 –

我不知道三角形队列，我会如果我的服务器处理成千上万的并发客户端（每个客户端需要一些deadline_timer情况下）探讨该解决方案后 – Ikarus

无限循环vs boost :: asio :: deadline_timer C++性能

回答

相关问题