std::condition_variable_any::wait_for
| template< class Lock, class Rep, class Period > std::cv_status wait_for( Lock& lock, |
(1) | (since C++11) |
| template< class Lock, class Rep, class Period, class Predicate > bool wait_for( Lock& lock, |
(2) | (since C++11) |
lock, blocks the current executing thread, and adds it to the list of threads waiting on *this. The thread will be unblocked when notify_all() or notify_one() is executed, or when the relative timeout rel_time expires. It may also be unblocked spuriously. When unblocked, regardless of the reason, lock is reacquired and wait_for() exits. If this function exits via exception, lock is also reacquired. (until C++14)A steady clock is used to measure the duration. This function may block for longer than timeout_duration due to scheduling or resource contention delays.
| If these functions fail to meet the postcondition (lock is locked by the calling thread), std::terminate is called. For example, this could happen if relocking the mutex throws an exception, | (since C++14) |
Parameters
| lock | - | an object of type Lock that meets the BasicLockable requirements, which must be locked by the current thread
|
| rel_time | - | an object of type std::chrono::duration representing the maximum time to spend waiting |
| pred | - | predicate which returns false if the waiting should be continued. The signature of the predicate function should be equivalent to the following: bool pred(); |
Return value
rel_time expired, std::cv_status::no_timeout otherwise.pred still evaluates to false after the rel_time timeout expired, otherwise true.Exceptions
|
May throw std::system_error, may also propagate exceptions thrown by lock.lock() or lock.unlock(). |
(until C++14) |
|
Any exception thrown by clock, time_point, or duration during the execution (clocks, time points, and durations provided by the standard library never throw) |
(since C++14) |
predNotes
Even if notified under lock, overload (1) makes no guarantees about the state of the associated predicate when returning due to timeout.
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.