std::condition_variable::wait_until 对 std::this_thread::sleep_for 有什么优势吗？答案

【问题标题】：Does std::condition_variable::wait_until have any advantage against std::this_thread::sleep_for?std::condition_variable::wait_until 对 std::this_thread::sleep_for 有什么优势吗？
【发布时间】：2019-07-02 09:02:02
【问题描述】：

在等待时间的场景中：

我们的软件在后台运行，并与每 20 - 30 分钟服务器一次。

我想用

std::this_thread::sleep_for

但我的上级强烈反对任何形式的睡眠功能。他推荐

std::condition_variable::wait_until(lock, timeout-time, pred)

我想知道在这种情况下 sleep_for 是否有任何缺点？

【问题讨论】：

什么是“这样的场景”？两者通常用于完全不同的场景
condition_variable 可以在超时之前唤醒。
如果你想无条件地睡觉，选择 1，如果你想等待一个条件并且限制为超时而不是使用 2。两者是完全不同的场景。 2 比 1 没有用，因为它“更好”。感觉就像“总是使用 for 循环语句，即使你只想要它的 if 子句。
例如，使用条件变量，您可以在从服务器接收数据时唤醒线程。此外，如果您连续睡眠 20 分钟，则在关闭应用程序时可能会出现问题（因为如果您使用 sleep_for，则无法唤醒线程以正确退出函数）。
这个错误陈述的问题，它类似于xy problem。

标签： c++ multithreading c++11

【解决方案1】：

正如 cmets 中已经指出的那样，它仅取决于您的用例。两者的主要区别在于，condition_variable 可以在你触发它的情况下提前唤醒。您还可以添加一个必须满足才能真正醒来的谓词，但这只是一种生活质量添加。顺便说一句，相当于sleep_for 是wait_for 而不是wait_until。 condition_variable 也非常适合在多个线程之间进行通信或同步。

鉴于你所说的一切，我会使用condition_variable，原因如下：

让线程长时间休眠并不是一个好主意，因为您的应用程序可以随时退出（或者更确切地说，可以请求退出）。在这种情况下，您可能希望线程正确退出，因此您必须能够随时唤醒它。
您想即时更改配置。如果您的线程必须使用新参数重新启动，或者如果您需要该线程实际加载配置文件，您也不想等待下一个 20 分钟间隔结束。

【讨论】：