From Jason Turner

[thread.barrier]

Diff to HTML by rtfpessoa

tmp/tmptu2mgzhn/{from.md → to.md} RENAMED
@@ -1,7 +1,9 @@
1
  ### Barriers <a id="thread.barrier">[[thread.barrier]]</a>
2
 
 
 
3
  A barrier is a thread coordination mechanism whose lifetime consists of
4
  a sequence of barrier phases, where each phase allows at most an
5
  expected number of threads to block until the expected number of threads
6
  arrive at the barrier.
7
 
@@ -49,17 +51,14 @@ namespace std {
49
 
50
  Each *barrier phase* consists of the following steps:
51
 
52
  - The expected count is decremented by each call to `arrive` or
53
  `arrive_and_drop`.
54
- - When the expected count reaches zero, the phase completion step is
55
- run. For the specialization with the default value of the
56
- `CompletionFunction` template parameter, the completion step is run as
57
- part of the call to `arrive` or `arrive_and_drop` that caused the
58
- expected count to reach zero. For other specializations, the
59
- completion step is run on one of the threads that arrived at the
60
- barrier during the phase.
61
  - When the completion step finishes, the expected count is reset to what
62
  was specified by the `expected` argument to the constructor, possibly
63
  adjusted by calls to `arrive_and_drop`, and the next phase starts.
64
 
65
  Each phase defines a *phase synchronization point*. Threads that arrive
 
1
  ### Barriers <a id="thread.barrier">[[thread.barrier]]</a>
2
 
3
+ #### General <a id="thread.barrier.general">[[thread.barrier.general]]</a>
4
+
5
  A barrier is a thread coordination mechanism whose lifetime consists of
6
  a sequence of barrier phases, where each phase allows at most an
7
  expected number of threads to block until the expected number of threads
8
  arrive at the barrier.
9
 
 
51
 
52
  Each *barrier phase* consists of the following steps:
53
 
54
  - The expected count is decremented by each call to `arrive` or
55
  `arrive_and_drop`.
56
+ - Exactly once after the expected count reaches zero, a thread executes
57
+ the completion step during its call to `arrive`, `arrive_and_drop`, or
58
+ `wait`, except that it is *implementation-defined* whether the step
59
+ executes if no thread calls `wait`.
 
 
 
60
  - When the completion step finishes, the expected count is reset to what
61
  was specified by the `expected` argument to the constructor, possibly
62
  adjusted by calls to `arrive_and_drop`, and the next phase starts.
63
 
64
  Each phase defines a *phase synchronization point*. Threads that arrive