sleep_until 过去的时间点 [英] sleep_until a timepoint in the past

问题描述

我有一个我认为很简单的模式 - 我想在未来 5 秒内设定一个时间点，运行一个可能需要一段时间的任务，然后睡眠到那个时间点(如果那个时间有可能根本不睡觉)已经达到.)但是，每当尝试使用 std::this_thread::sleep_until 和过去的时间点时，我的应用程序反而永远挂起.这是一个 MCVE:

I have what I thought was a simple pattern - I want to make a timepoint 5 seconds in the future, run a task which might take a while, and then sleep until that timepoint (potentially not sleeping at all if that time has already been reached.) However, whenever trying to use std::this_thread::sleep_until with a timepoint in the past, my application instead hangs forever. Here is an MCVE:

#include <chrono>
#include <thread>

int main(){
  std::this_thread::sleep_until(std::chrono::steady_clock::now() - std::chrono::seconds(1));
}

使用 g++ (GCC) 4.8.5，这永远不会返回.我也试过 system_clock ，结果相同.使用 strace 检查发生了什么，我得到的最后一件事是:

Using g++ (GCC) 4.8.5, this never returns. I've also tried system_clock with the same results. Using strace to examine what's happening, the last thing I get is:

nanosleep({4294967295, 0},

所以我想它最终会回来，但我不想等那么久.

so I guess it would return eventually, but I don't feel like waiting that long.

这是一个 g++ 错误吗?我无法想象这种行为是故意的.我发现了这个问题 当 sleep_until() 指定过去的某个时间点时，行为是否定义明确? 但似乎实际上并未就标准是否实际指定应该做什么得出任何结论发生.从那以后，我为我的问题实施了另一种解决方案；我只是好奇我看到的是 UB 还是 bug.

Is this a g++ bug? I can't imagine this behavior is intentional. I found the question Is behaviour well-defined when sleep_until() specifies a time point in the past? but it doesn't seem that any conclusion was actually reached on whether or not the standard actually specifies what should happen. I've since implemented another solution to my problem; I'm just curious as to whether or not what I'm seeing is UB or a bug.

推荐答案

看起来像一个错误:

4  名称以 _until 结尾的函数采用指定时间点的参数.这些函数产生绝对超时.实现应该使用时间点中指定的时钟来测量这些函数的时间.给定一个时钟时间点参数C_t，timeout返回的时钟时间点应该是C_t+D_i+D_m 超时期间不调整时钟.(...)

30.2.4 Timing specifications [thread.req.timing]

4   The functions whose names end in _­until take an argument that specifies a time point. These functions produce absolute timeouts. Implementations should use the clock specified in the time point to measure time for these functions. Given a clock time point argument C_t, the clock time point of the return from timeout should be C_t+D_i+D_m when the clock is not adjusted during the timeout. (...)

其中 D_i 定义为实施质量"延迟，D_m 定义为管理质量"延迟.

Where D_i is defined as a "quality of implementation" delay, and D_m is defined as a "quality of management" delay.

正如 Howard Hinnant 出色地强调的，实现应该努力最小化 D_i 和 D_m:

As Howard Hinnant brilliantly emphasizes, an implementation should strive to minimize D_i and D_m:

2  实现在从超时返回时必然有一些延迟.中断响应、函数返回和调度中的任何开销都会导致实现质量"延迟，表示为持续时间 D_i.理想情况下，此延迟为零.此外，对处理器和内存资源的任何争用都会导致管理质量"延迟，表示为持续时间 D_m.延迟持续时间可能因超时而异，但在所有情况下越短越好.

30.2.4 Timing specifications [thread.req.timing]

2   Implementations necessarily have some delay in returning from a timeout. Any overhead in interrupt response, function return, and scheduling induces a "quality of implementation" delay, expressed as duration D_i. Ideally, this delay would be zero. Further, any contention for processor and memory resources induces a "quality of management" delay, expressed as duration D_m. The delay durations may vary from timeout to timeout, but in all cases shorter is better.

请注意，无论 C_t 的值是多少，这都必须是正确的，并且 无限 延迟绝对不是最小的.

Note that this must be true no matter what the value of C_t is, and that an infinite delay is definitely not minimal.

作为一个小更新，此问题现已修复，从 4.9 版开始.3.这是有关错误跟踪器的信息.

As a small update, this is now fixed, as of version 4.9.3. Here is the information on the bug tracker.

这篇关于sleep_until 过去的时间点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！