当 `sleep_until()` 指定过去的时间点时，行为是否明确？答案

【问题标题】：Is behaviour well-defined when `sleep_until()` specifies a time point in the past?当 `sleep_until()` 指定过去的时间点时，行为是否明确？
【发布时间】：2016-10-04 09:02:13
【问题描述】：

C++11 标准讨论了如果调整系统时钟以使传递给 sleep_until() 的时间点现在已经过去会发生什么 - 但我看不到任何地方可以解决指定的情况时间点已经过去了。

我是否只是忽略了某些东西，或者它真的没有指定 - 即使是 UB 或实现定义的？

如果以负的持续时间调用sleep_for()，则会出现类似的问题。

【问题讨论】：

这并不是您在此处解决的具体编码案例或问题。这更像是一个讨论
@Rockbar：这个问题非常具体，而且是一个结构完美的问题。
我记得，规范提供了不同的时钟。有些保证是强烈单调递增的（不要跳回），有些则不是。
@Rockbar：这不是一个普遍的问题。根据特定的语言标准，这是关于特定语言的特定行为的特定问题。 Stack Overflow 实际上应该是针对这些令人敬畏的问题，而不是我们被垃圾邮件发送的无休止的“为我调试我的代码”废话！我们想要更多，而不是更少！
我在这里和@light 比赛

标签： c++ c++11 language-lawyer chrono stdthread

【解决方案1】：

睡眠和调用sleep_until() 的时间计算不是原子的。您可能会计算时间，然后发生上下文切换，系统过载，交换以及对sleep_until() 的实际调用发生得更晚。所以如果sleep_until()没有在时间过去的时候唤醒，那么它是没有用的，因为在这种情况下你永远不能确定你的线程会被唤醒。

该功能的要求在标准的第 30.2.4 节中指定。它指定返回时间应该是 Ct + Di + Dm 其中 Ct 是您指定的时间，Di 是开销 oof 中断、函数返回和调度引起的延迟，Dm 是资源争用引起的延迟。在这种情况下，Di 包括在您调用 sleep_until() 之前经过的时间，并且该函数会尽快返回。

【讨论】：

我不同意 - Di 被描述为“实施质量”延迟。我们在这里讨论的是一个逻辑问题，即使 Di 和 Dm（“管理质量”延迟）都为零。
sleep_until 需要在 Ct + + 时返回。在这种情况下，我们需要大量时间来安排它，因为我们希望它在昨天完成。
是的，任何延迟都可能在程序的任何地方引入，这意味着当您调用std::sleep_until(x) 时，x 可能已经过去了。即使你这样做if (x > SomeClock::now()) std::sleep_until(x);。在这方面，唯一合理/可靠的实现是将过去的超时视为（已经）达到。

【解决方案2】：

你分析得太多了。

标准是否明确表示“如果目标时间在过去，则不会阻塞或等待”？没有。

它是否特意解释了时间步将如何缩小或消除超时？是的。此外，它根据相对超时来定义这些超时。

意图，我认为是相当清楚的。这是您可以但必须从英文措辞中推断出来的情况之一：如果立即满足超时，则不会发生任何事情。

更有趣的是，在任何一种情况下，似乎都没有明确定义是否会有瞬时锁定和解锁循环。

【讨论】：

即使在调用时是在未来，当控制到达调度程序的实现时也可能是在过去。所以我不确定指定“过去”时间的行为是否存在固有问题。
@JohannesSchaub-litb：这是一个实现问题
再想一想，指定过去的时间可能会出现问题，但是对于单调时钟，可以保证过去的时间过去。
“我认为意图相当明确”——万恶之源。

【解决方案3】：

From here

阻塞当前线程的执行直到指定的 sleep_time 已到达。

即如果时间是过去，那么它不会阻塞很长时间。

【讨论】：

cppreference.com 不是 ISO 标准文档
我会找到一个更好的参考然后：P
从这里open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf "阻塞调用线程的绝对超时" 很明显，如果绝对超时已经过去，那么阻塞将很快过期。
OTOH 可以说负的绝对超时不存在，因此没有正式的定义。然后，您可能无法依赖实现来执行特定的、定义明确的事情。我个人认为这种可能性很低，但正如我在回答中所说，这种情况确实没有实际措辞。
完全正确 - 没有任何措辞，这意味着它会引发任何类型的错误，因为它已经在 ISO 中说明了引发错误的条件。