较长的睡眠(在C ++中)是否比较短的睡眠更不精确 [英] Are longer sleeps (in C++) less precise than short ones

问题描述

我有一项任务是每隔一分钟(在xx:xx:00进行一次) 我用类似的东西

I have a task to do something every "round" minute(at xx:xx:00) And I use something like

const int statisticsInterval=60;
    time_t t=0;
    while (1)
    {
        if (abs(t-time(NULL)==0))   //to avoid multiple calls in the same second that is the multiple of 60
                boost::this_thread::sleep(boost::posix_time::seconds(2));//2, not 1 to make sure that 1 second passes

        t=time(NULL);
        boost::this_thread::sleep(boost::posix_time::seconds(statisticsInterval-(t%statisticsInterval)));

        //DO WORK
    }

如您所见，我使用睡眠(60秒-当前分钟中经过的秒数).但是一位程序员告诉我，这并不精确，我应该将其更改为 while循环，里面带有sleep(1).我认为他是对的人表示高度怀疑，但我只是想检查一下是否有人知道，如果睡眠间隔长，精度会降低. 我认为睡眠的实现方式是在将来的特定时间激活触发器，并将线程置于准备执行线程组"，因此我认为没有理由在精度上有所差异. BTW OS是ubuntu，我不在乎少于2-3秒的错误.例如，如果我睡52秒钟，那么53.8睡眠是完全可以接受的. P.S.我知道定义最小时间的睡眠，理论上讲，我的线程可能会在2047年被激活.

As you can see I use sleep (60sec - number of elapsed seconds in current minute). But one programmer told me that it is not precise and that i should change it to while loop with sleep(1) inside. I consider it highly doubtful that he is right, but I just wanted to check is somebody knows if there is less of a precision if the sleep interval is long. I presume that sleep is implemented in a way that at certain time in the future trigger is activated and thread is put into "ready to execute thread group" so I see no reason for diff in precision. BTW OS is ubuntu and I dont care about less than 2-3 sec errors. For example if I sleep for 52 secs, 53.8 sleep is totally acceptable. P.S. I know about sleep defining the minimal time, and that theoretically my thread might get activated in year 2047., but I'm asking about realistic scenarios.

推荐答案

在某些线程API中，有可能在 完成之前被唤醒(例如，由于信号在休眠期间到达) .解决此问题的正确方法是计算绝对唤醒时间，然后循环，在剩余时间内休眠.我可以想象，每隔一秒钟睡一下就很糟糕了.

In some threading APIs, it's possible to be awoken before the sleep completes (eg, due to a signal arriving during the sleep). The correct way to handle this is to compute an absolute wake up time, then loop, sleeping for the remaining duration. I would imagine sleeping for one-second intervals to be a hack to approximate this, poorly.

但是，boost线程API的 <没有记录c0> 具有这些早期唤醒功能，因此该技术不是必需的(增强线程API会为您执行循环).

However, the boost threading API's this_thread::sleep() is not documented to have these early wakeups, and so this technique is not necessary (the boost thread API does the loop for you).

通常来说，很少有使用较小的睡眠间隔可以显着改善唤醒潜伏期的情况.操作系统或多或少以相同的方式处理所有唤醒.充其量，您可以保持高速缓存的温暖并避免分页，但这只会影响睡眠循环中直接涉及的一小部分内存.

Generally speaking, there are very few cases where using smaller sleep intervals improves wakeup latency significantly; the OS handles all wakeups more or less the same way. At best, you might keep the cache warm and avoid pageouts, but this would only affect the small portion of memory directly involved in the sleep loop.

此外，大多数操作系统内部都使用整数计数器来处理时间.这意味着大的间隔不会引起舍入误差(如浮点值可能会发现).但是，如果 you 使用浮点数进行自己的计算，则可能会出现问题.如果当前正在使用浮点间隔(例如，自1970年以来为double秒)，则不妨考虑整数单位(例如，自1970年以来以毫秒为long long).

Furthermore, most OSes deal with time using integer counters internally; this means that large intervals do not induce rounding errors (as you might find with floating point values). However, if you are using floating point for your own computation, this may be an issue. If you are currently using floating point intervals (say, a double of seconds since 1970), you may wish to consider integer units (say, a long long of milliseconds since 1970).

这篇关于较长的睡眠(在C ++中)是否比较短的睡眠更不精确的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！