tmp/tmpicbinu65/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,30 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
### General <a id="thread.condition.general">[[thread.condition.general]]</a>
|
| 2 |
+
|
| 3 |
+
Condition variables provide synchronization primitives used to block a
|
| 4 |
+
thread until notified by some other thread that some condition is met or
|
| 5 |
+
until a system time is reached. Class `condition_variable` provides a
|
| 6 |
+
condition variable that can only wait on an object of type
|
| 7 |
+
`unique_lock<mutex>`, allowing the implementation to be more efficient.
|
| 8 |
+
Class `condition_variable_any` provides a general condition variable
|
| 9 |
+
that can wait on objects of user-supplied lock types.
|
| 10 |
+
|
| 11 |
+
Condition variables permit concurrent invocation of the `wait`,
|
| 12 |
+
`wait_for`, `wait_until`, `notify_one` and `notify_all` member
|
| 13 |
+
functions.
|
| 14 |
+
|
| 15 |
+
The executions of `notify_one` and `notify_all` are atomic. The
|
| 16 |
+
executions of `wait`, `wait_for`, and `wait_until` are performed in
|
| 17 |
+
three atomic parts:
|
| 18 |
+
|
| 19 |
+
1. the release of the mutex and entry into the waiting state;
|
| 20 |
+
2. the unblocking of the wait; and
|
| 21 |
+
3. the reacquisition of the lock.
|
| 22 |
+
|
| 23 |
+
The implementation behaves as if all executions of `notify_one`,
|
| 24 |
+
`notify_all`, and each part of the `wait`, `wait_for`, and `wait_until`
|
| 25 |
+
executions are executed in a single unspecified total order consistent
|
| 26 |
+
with the “happens before” order.
|
| 27 |
+
|
| 28 |
+
Condition variable construction and destruction need not be
|
| 29 |
+
synchronized.
|
| 30 |
+
|