提高deadline_timer移10毫秒 [英] boost deadline_timer shift 10 milliseconds

问题描述

有任何人遇到了后来deadline_timer不断调用下一个回调函数与10毫秒？难道正常吗？

该操作系统是CentOS 6的和提升的版本是1.54。

例如

  16年8月14日：36：01.697
16年8月14日：36：02.706
16年8月14日：36：03.716
16年8月14日：36：04.726
16年8月14日：36：05.736
16年8月14日：36：06.746
16年8月14日：36：07.756
16年8月14日：36：08.766
16年8月14日：36：09.776
16年8月14日：36：10.786
16年8月14日：36：11.796
16年8月14日：36：12.806
16年8月14日：36：13.816
16年8月14日：36：14.826
16年8月14日：36：15.836
16年8月14日：36：16.846
16年8月14日：36：17.856
 

在code看起来像下面

  //的std ::的unique_ptr＆LT;提高:: ASIO :: deadline_timer＆GT; m_poTimer;无效timerExpired（常量的boost ::系统::错误_ code和; oError）
    {
        如果（！oError）
        {
            m_poTimer-＆GT; expires_from_now（升压::了posix_time ::毫秒（1000））;
            m_poTimer-＆GT; async_wait（的std ::绑定（安培; timerExpired，对此，性病::占位符:: _ 1））;
        }
        其他
        {        }
    }
 

解决方案

像通用分时操作系统上的任何应用层的定时器，它基本上是不可能完成的precise时间后，以保证执行。你的操作系统在不断的code进程和线程之间的上下文切换，大约有5-10ms分辨率通常和没有中断立即执行的CPU没有东西唤醒它，并检查计时摆在首位的方法。

所有应用层的定时器是至少 T 的，并没有什么可以做这一点。

我承认奇怪，你有这样的可靠和可重复的模式，但无论哪种：

• 这是你的环境的因素（我们不能说），或


• 这是库（我看不出有什么证据）的一个因素，或


• 这是你的code的一个因素（我们不能告诉，因为你没有present一个测试用例），或


• 这仅仅是由上述事实创造了一个异常，你不能做任何事情。

Have anyone encounter that the deadline_timer call the next callback function with 10 millisecond later constantly? Is it expected?

The OS is centos 6 and boost version is 1.54.

e.g.

Aug 14 16:36:01.697
Aug 14 16:36:02.706
Aug 14 16:36:03.716
Aug 14 16:36:04.726
Aug 14 16:36:05.736
Aug 14 16:36:06.746
Aug 14 16:36:07.756
Aug 14 16:36:08.766
Aug 14 16:36:09.776
Aug 14 16:36:10.786
Aug 14 16:36:11.796
Aug 14 16:36:12.806
Aug 14 16:36:13.816
Aug 14 16:36:14.826
Aug 14 16:36:15.836
Aug 14 16:36:16.846
Aug 14 16:36:17.856

the code looks like below

// std::unique_ptr<boost::asio::deadline_timer> m_poTimer;

void timerExpired(const boost::system::error_code& oError)
    {
        if (!oError)
        {
            m_poTimer->expires_from_now(boost::posix_time::millisec(1000));
            m_poTimer->async_wait(std::bind(&timerExpired, this, std::placeholders::_1));
        }
        else
        {

        }
    }

解决方案

Like any application-layer timer on a general purpose time-shared operating system, it is fundamentally impossible to guarantee execution after a precise time. Your OS is constantly context-switching between processes and threads, usually with around 5-10ms resolution, and your code has no way of interrupting the CPU for immediate execution without something to wake it up and check the timer in the first place.

All application-layer timers are for "at least t" and there's nothing you can do about that.

I concede surprise that you have such a reliable and repeatable pattern, but either:

• this is a factor of your environment (which we can't speak to), or
• this is a factor of the library (for which I can see no evidence), or
• this is a factor of your code (which we can't tell because you did not present a testcase), or
• this is simply an anomaly created by the above facts, and you can't do anything about it.

这篇关于提高deadline_timer移10毫秒的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！