RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://en.cppreference.com/w/cpp/language/../header/../thread/condition_variable/wait_for.html below:

std::condition_variable::wait_for - cppreference.com

wait_for causes the current thread to block until the condition variable is notified, the given duration has been elapsed, or a spurious wakeup occurs. pred can be optionally provided to detect spurious wakeup.

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

Right after wait_for 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.

[edit] Parameters lock - a lock which must be locked by the calling thread rel_time - the maximum duration to wait 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] Return value

2) The latest result of pred() before returning to the caller.

[edit] Exceptions

1) Timeout-related exceptions.

2) Timeout-related exceptions, and any exception thrown by pred.

[edit] Notes

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.

[edit] Example

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 2093 C++11 timeout-related exceptions were missing in the specification mentions these exceptions 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 blocks the current thread until the condition variable is awakened
(public member function) [edit] blocks the current thread until the condition variable is awakened or until specified time point has been reached
(public member function) [edit]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4