std::condition_variable::wait

void wait( std::unique_lock<std::mutex>& lock );	(1)	(since C++11)
template< class Predicate > void wait( std::unique_lock<std::mutex>& lock, Predicate pred );	(2)	(since C++11)

wait causes the current thread to block until the condition variable is notified or a spurious wakeup occurs. pred can be optionally provided to detect spurious wakeup.

1) Atomically calls lock.unlock() and blocks on *this.

The thread will be unblocked when notify_all() or notify_one() is executed. It may also be unblocked spuriously.

When unblocked, calls lock.lock() (possibly blocking on the lock), then returns.

2) Equivalent to

while (!pred())
wait(lock);.

This overload may be used to ignore spurious awakenings while waiting for a specific condition to become true.

Right after wait returns, lock.owns_lock() is true, and lock.mutex() is locked by the calling thread. If these postconditions cannot be satisfied^[1], calls std::terminate.

If any of the following conditions is satisfied, the behavior is undefined:

lock.owns_lock() is false.
lock.mutex() is not locked by the calling thread.
If some other threads are also waiting on *this, lock.mutex() is different from the mutex unlocked by the waiting functions (wait, wait_for and wait_until) called on *this by those threads.

↑ This can happen if the re-locking of the mutex throws an exception.

lock	-	an lock which must be locked by the calling thread
pred	-	the predicate to check whether the waiting can be completed
Type requirements
- `Predicate` must meet the requirements of FunctionObject.
- pred() must be a valid expression, and its type and value category must meet the BooleanTestable requirements.

[edit] Exceptions

1) Throws nothing.

2) Any exception thrown by pred.

[edit] Notes

The effects of notify_one()/notify_all() and each of the three atomic parts of wait()/wait_for()/wait_until() (unlock+wait, wakeup, and lock) take place in a single total order that can be viewed as modification order of an atomic variable: the order is specific to this individual condition variable. This makes it impossible for notify_one() to, for example, be delayed and unblock a thread that started waiting just after the call to notify_one() was made.

[edit] Example

Run this code

#include <chrono>
#include <condition_variable>
#include <iostream>
#include <thread>
 
std::condition_variable cv;
std::mutex cv_m; // This mutex is used for three purposes:
                 // 1) to synchronize accesses to i
                 // 2) to synchronize accesses to std::cerr
                 // 3) for the condition variable cv
int i = 0;
 
void waits()
{
    std::unique_lock<std::mutex> lk(cv_m);
    std::cerr << "Waiting... \n";
    cv.wait(lk, []{ return i == 1; });
    std::cerr << "...finished waiting. i == 1\n";
}
 
void signals()
{
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lk(cv_m);
        std::cerr << "Notifying...\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 << "Notifying again...\n";
    }
    cv.notify_all();
}
 
int main()
{
    std::thread t1(waits), t2(waits), t3(waits), t4(signals);
    t1.join(); 
    t2.join(); 
    t3.join();
    t4.join();
}

Possible output:

Waiting...
Waiting...
Waiting...
Notifying...
Notifying again...
...finished waiting. i == 1
...finished waiting. i == 1
...finished waiting. i == 1

[edit] Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR	Applied to	Behavior as published	Correct behavior
LWG 2114 (P2167R3)	C++11	convertibility to bool was too weak to reflect the expectation of implementations	requirements strengthened
LWG 2135	C++11	the behavior was unclear if lock.lock() throws an exception	calls std::terminate in this case

[edit] See also

wait_for	blocks the current thread until the condition variable is awakened or after the specified timeout duration (public member function) [edit]
wait_until	blocks the current thread until the condition variable is awakened or until specified time point has been reached (public member function) [edit]
C documentation for cnd_wait

[edit] External links

1.	The Old New Thing article: Spurious wake-ups in Win32 condition variables.

[1] This can happen if the re-locking of the mutex throws an exception.

[1]

Compiler support
Freestanding and hosted
Language
Standard library
Standard library headers
Named requirements
Feature test macros (C++20)
Language support library
Concepts library (C++20)
Metaprogramming library (C++11)
Diagnostics library
General utilities library
Strings library
Containers library
Iterators library
Ranges library (C++20)
Algorithms library
Numerics library
Localizations library
Input/output library
Filesystem library (C++17)
Regular expressions library (C++11)
Concurrency support library (C++11)
Execution support library (C++26)
Technical specifications
Symbols index
External libraries

Member functions
condition_variable::condition_variable
condition_variable::~condition_variable
Notification
condition_variable::notify_one
condition_variable::notify_all
Waiting
condition_variable::wait
condition_variable::wait_for
condition_variable::wait_until
Native handle
condition_variable::native handle

cppreference.com

Namespaces

Variants

Views

Actions

std::condition_variable::wait

Contents

[edit] Parameters