boost::this_thread::sleep_for 的睡眠时间比我预期的要长得多。

Posted 2023-02-22

【中文标题】boost::this_thread::sleep_for 的睡眠时间比我预期的要长得多。

【英文标题】：boost::this_thread::sleep_for sleeps much longer than I expect.

【发布时间】：2015-12-01 00:05:03

【问题描述】：

我在我的多线程项目中使用了 boost sleep_for，发现它的睡眠时间比我预期的要长得多。

这样的声明：

boost::this_thread::sleep_for(boost::chrono::milliseconds(100));

可能需要 0.1 秒或 2 秒甚至 10 秒。

但在我的测试程序中，它运行良好。

int main(void)

    for (int i = 0; i < 100; i++) 
        auto start = boost::chrono::system_clock::now();
        boost::this_thread::sleep_for(boost::chrono::milliseconds(100));
        auto end = boost::chrono::system_clock::now();

        std::cout << (end-start).count() << std::endl;
    
    return 0;

我在 Mac Os 10.10 上使用 clang-602.0.53，Boost 版本是 1.58。

【问题讨论】：

使用 sleep_until 如果您想要更强有力的保证，您将在某个截止日期前被唤醒。 sleep_for 仅提供尽力而为的睡眠，它可能是不睡眠或睡眠时间比请求的时间长。

已测试 sleep_until。结果与 sleep_for 相同。 [似乎这两个功能都不能给我保证。 ](en.cppreference.com/w/cpp/thread/sleep_until)

另一件事是尝试最新的Boost。几个版本前的计时器计算中存在一些错误。老实说，我承认他们是我介绍的:)

感谢您的帮助。但我发现这不应该是一个提升问题。我的应用程序是 Qt 应用程序，如果我删除所有 Qt 代码，此问题不会显示。我得到另一个答案说这是由 OS X 的 App Nap 功能引起的。我正在调查它。 ***.com/questions/34053980/…

【参考方案1】：

Boost 的 sleep_for 在大多数非 Windows 平台 (source) 上使用 POSIX nanosleep() 函数。由内核决定何时唤醒挂起的线程。

如果系统上有大量活动（大量线程在做大量工作），那么操作系统的线程调度程序可能需要一段时间才能唤醒线程。 nanosleep() 只保证你的线程在指定的持续时间之前不会被唤醒——它不保证持续时间过去后的准确性。

我敢打赌，如果您更改测试程序以生成大量工作线程（比调用 now() 的计算量更大），那么准确度将会直线下降。