std::condition_variable:: wait_until

wait_until 使当前线程阻塞，直到条件变量被通知、到达指定时间点或发生伪唤醒。可选择性地提供 pred 来检测伪唤醒。

当 wait_until 返回后， lock. owns_lock ( ) 为 true ，且 lock. mutex ( ) 已被调用线程锁定。若无法满足这些后置条件 ^[1] ，将调用 std::terminate 。

若满足以下任一条件，则行为未定义：

• lock. owns_lock ( ) 为 false 。
• lock. mutex ( ) 未被调用线程锁定。
• 若其他线程也在等待 * this ，则 lock. mutex ( ) 与这些线程通过等待函数（ wait 、 wait_for 和 wait_until ）在 * this 上解锁的互斥量不同。

1. ↑ 这种情况可能发生在互斥锁重新加锁时抛出异常的情况下。

参数

返回值

异常

注释

标准建议使用与 abs_time 绑定的时钟来测量时间；该时钟不要求是单调时钟。如果时钟被不连续调整，此函数的行为不作保证，但现有实现会将 abs_time 从 Clock 转换为 std::chrono::system_clock 并委托给POSIX pthread_cond_timedwait ，因此等待过程会遵循系统时钟的调整，但不会遵循用户提供的 Clock 的调整。在任何情况下，由于调度或资源竞争延迟，该函数的实际等待时间可能会超过 abs_time 所指定的时间点。

即使使用的时钟是 std::chrono::steady_clock 或其他单调时钟，系统时钟调整仍可能引发虚假唤醒。

notify_one() / notify_all() 的效果以及 wait() / wait_for() / wait_until() 的三个原子操作部分（解锁+等待、唤醒和加锁）的发生顺序构成一个单一的全序，可视为原子变量的 修改顺序 ：该顺序特定于此条件变量。这使得例如 notify_one() 不可能被延迟，并解除那些恰好在 notify_one() 调用之后才开始等待的线程的阻塞状态。

示例

#include <chrono>
#include <condition_variable>
#include <iostream>
#include <thread>
std::condition_variable cv;
std::mutex cv_m; // 此互斥锁用于三个目的：
                 // 1) 同步对 i 的访问
                 // 2) 同步对 std::cerr 的访问
                 // 3) 用于条件变量 cv
int i = 0;
void waits()
{
    std::unique_lock<std::mutex> lk(cv_m);
    std::cerr << "等待中... \n";
    cv.wait(lk, []{ return i == 1; });
    std::cerr << "...等待结束。i == 1\n";
}
void signals()
{
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lk(cv_m);
        std::cerr << "正在通知...\n";
    }
    cv.notify_all();
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lk(cv_m);
        i = 1;
        std::cerr << "再次通知...\n";
    }
    cv.notify_all();
}
int main()
{
    std::thread t1(waits), t2(waits), t3(waits), t4(signals);
    t1.join(); 
    t2.join(); 
    t3.join();
    t4.join();
}

等待中...
等待中...
等待中...
正在通知...
再次通知...
...等待结束。i == 1
...等待结束。i == 1
...等待结束。i == 1

缺陷报告

以下行为变更缺陷报告被追溯应用于先前发布的C++标准。

参见