tmp/tmp6mk984dc/{from.md → to.md}
RENAMED
|
@@ -1,14 +1,18 @@
|
|
| 1 |
## Coordination types <a id="thread.coord">[[thread.coord]]</a>
|
| 2 |
|
| 3 |
-
|
|
|
|
|
|
|
| 4 |
coordination, and defines the coordination types `latch` and `barrier`.
|
| 5 |
These types facilitate concurrent computation performed by a number of
|
| 6 |
threads.
|
| 7 |
|
| 8 |
### Latches <a id="thread.latch">[[thread.latch]]</a>
|
| 9 |
|
|
|
|
|
|
|
| 10 |
A latch is a thread coordination mechanism that allows any number of
|
| 11 |
threads to block until an expected number of threads arrive at the latch
|
| 12 |
(via the `count_down` function). The expected count is set when the
|
| 13 |
latch is created. An individual latch is a single-use object; once the
|
| 14 |
expected count has been reached, the latch cannot be reused.
|
|
@@ -121,10 +125,12 @@ count_down(update);
|
|
| 121 |
wait();
|
| 122 |
```
|
| 123 |
|
| 124 |
### Barriers <a id="thread.barrier">[[thread.barrier]]</a>
|
| 125 |
|
|
|
|
|
|
|
| 126 |
A barrier is a thread coordination mechanism whose lifetime consists of
|
| 127 |
a sequence of barrier phases, where each phase allows at most an
|
| 128 |
expected number of threads to block until the expected number of threads
|
| 129 |
arrive at the barrier.
|
| 130 |
|
|
@@ -172,17 +178,14 @@ namespace std {
|
|
| 172 |
|
| 173 |
Each *barrier phase* consists of the following steps:
|
| 174 |
|
| 175 |
- The expected count is decremented by each call to `arrive` or
|
| 176 |
`arrive_and_drop`.
|
| 177 |
-
-
|
| 178 |
-
|
| 179 |
-
`
|
| 180 |
-
|
| 181 |
-
expected count to reach zero. For other specializations, the
|
| 182 |
-
completion step is run on one of the threads that arrived at the
|
| 183 |
-
barrier during the phase.
|
| 184 |
- When the completion step finishes, the expected count is reset to what
|
| 185 |
was specified by the `expected` argument to the constructor, possibly
|
| 186 |
adjusted by calls to `arrive_and_drop`, and the next phase starts.
|
| 187 |
|
| 188 |
Each phase defines a *phase synchronization point*. Threads that arrive
|
|
|
|
| 1 |
## Coordination types <a id="thread.coord">[[thread.coord]]</a>
|
| 2 |
|
| 3 |
+
### General <a id="thread.coord.general">[[thread.coord.general]]</a>
|
| 4 |
+
|
| 5 |
+
Subclause [[thread.coord]] describes various concepts related to thread
|
| 6 |
coordination, and defines the coordination types `latch` and `barrier`.
|
| 7 |
These types facilitate concurrent computation performed by a number of
|
| 8 |
threads.
|
| 9 |
|
| 10 |
### Latches <a id="thread.latch">[[thread.latch]]</a>
|
| 11 |
|
| 12 |
+
#### General <a id="thread.latch.general">[[thread.latch.general]]</a>
|
| 13 |
+
|
| 14 |
A latch is a thread coordination mechanism that allows any number of
|
| 15 |
threads to block until an expected number of threads arrive at the latch
|
| 16 |
(via the `count_down` function). The expected count is set when the
|
| 17 |
latch is created. An individual latch is a single-use object; once the
|
| 18 |
expected count has been reached, the latch cannot be reused.
|
|
|
|
| 125 |
wait();
|
| 126 |
```
|
| 127 |
|
| 128 |
### Barriers <a id="thread.barrier">[[thread.barrier]]</a>
|
| 129 |
|
| 130 |
+
#### General <a id="thread.barrier.general">[[thread.barrier.general]]</a>
|
| 131 |
+
|
| 132 |
A barrier is a thread coordination mechanism whose lifetime consists of
|
| 133 |
a sequence of barrier phases, where each phase allows at most an
|
| 134 |
expected number of threads to block until the expected number of threads
|
| 135 |
arrive at the barrier.
|
| 136 |
|
|
|
|
| 178 |
|
| 179 |
Each *barrier phase* consists of the following steps:
|
| 180 |
|
| 181 |
- The expected count is decremented by each call to `arrive` or
|
| 182 |
`arrive_and_drop`.
|
| 183 |
+
- Exactly once after the expected count reaches zero, a thread executes
|
| 184 |
+
the completion step during its call to `arrive`, `arrive_and_drop`, or
|
| 185 |
+
`wait`, except that it is *implementation-defined* whether the step
|
| 186 |
+
executes if no thread calls `wait`.
|
|
|
|
|
|
|
|
|
|
| 187 |
- When the completion step finishes, the expected count is reset to what
|
| 188 |
was specified by the `expected` argument to the constructor, possibly
|
| 189 |
adjusted by calls to `arrive_and_drop`, and the next phase starts.
|
| 190 |
|
| 191 |
Each phase defines a *phase synchronization point*. Threads that arrive
|