From Jason Turner

[intro.progress]

C++20 → C++23 8.2 KB 48 lines
Current Draft | LaTeX Source
Archived: C++20 | C++23
Markdown: C++20 | C++23
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp0cixhnhp/{from.md → to.md} +20 -22
tmp/tmp0cixhnhp/{from.md → to.md} RENAMED
@@ -16,25 +16,25 @@ Executions of atomic functions that are either defined to be lock-free
16
  [[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
17
  *lock-free executions*.
18
 
19
  - If there is only one thread that is not blocked [[defns.block]] in a
20
  standard library function, a lock-free execution in that thread shall
21
- complete. \[*Note 2*: Concurrently executing threads may prevent
22
  progress of a lock-free execution. For example, this situation can
23
  occur with load-locked store-conditional implementations. This
24
  property is sometimes termed obstruction-free. — *end note*]
25
  - When one or more lock-free executions run concurrently, at least one
26
  should complete. \[*Note 3*: It is difficult for some implementations
27
  to provide absolute guarantees to this effect, since repeated and
28
- particularly inopportune interference from other threads may prevent
29
  forward progress, e.g., by repeatedly stealing a cache line for
30
  unrelated purposes between load-locked and store-conditional
31
- instructions. Implementations should ensure that such effects cannot
32
- indefinitely delay progress under expected operating conditions, and
33
- that such anomalies can therefore safely be ignored by programmers.
34
- Outside this document, this property is sometimes termed
35
- lock-free. — *end note*]
36
 
37
  During the execution of a thread of execution, each of the following is
38
  termed an *execution step*:
39
 
40
  - termination of the thread of execution,
@@ -46,11 +46,11 @@ An invocation of a standard library function that blocks [[defns.block]]
46
  is considered to continuously execute execution steps while waiting for
47
  the condition that it blocks on to be satisfied.
48
 
49
  [*Example 1*: A library I/O function that blocks until the I/O
50
  operation is complete can be considered to continuously check whether
51
- the operation is complete. Each such check might consist of one or more
52
  execution steps, for example using observable behavior of the abstract
53
  machine. — *end example*]
54
 
55
  [*Note 4*: Because of this and the preceding requirement regarding what
56
  threads of execution have to perform eventually, it follows that no
@@ -65,30 +65,28 @@ concurrent threads that are not blocked in a standard library function
65
  For a thread of execution providing *concurrent forward progress
66
  guarantees*, the implementation ensures that the thread will eventually
67
  make progress for as long as it has not terminated.
68
 
69
  [*Note 5*: This is required regardless of whether or not other threads
70
- of executions (if any) have been or are making progress. To eventually
71
  fulfill this requirement means that this will happen in an unspecified
72
  but finite amount of time. — *end note*]
73
 
74
  It is *implementation-defined* whether the implementation-created thread
75
  of execution that executes `main` [[basic.start.main]] and the threads
76
  of execution created by `std::thread` [[thread.thread.class]] or
77
  `std::jthread` [[thread.jthread.class]] provide concurrent forward
78
- progress guarantees.
79
-
80
- [*Note 6*: General-purpose implementations should provide these
81
- guarantees. — *end note*]
82
 
83
  For a thread of execution providing *parallel forward progress
84
  guarantees*, the implementation is not required to ensure that the
85
  thread will eventually make progress if it has not yet executed any
86
  execution step; once this thread has executed a step, it provides
87
  concurrent forward progress guarantees.
88
 
89
- [*Note 7*: This does not specify a requirement for when to start this
90
  thread of execution, which will typically be specified by the entity
91
  that creates this thread of execution. For example, a thread of
92
  execution that provides concurrent forward progress guarantees and
93
  executes tasks from a set of tasks in an arbitrary order, one after the
94
  other, satisfies the requirements of parallel forward progress for these
@@ -96,57 +94,57 @@ tasks. — *end note*]
96
 
97
  For a thread of execution providing *weakly parallel forward progress
98
  guarantees*, the implementation does not ensure that the thread will
99
  eventually make progress.
100
 
101
- [*Note 8*: Threads of execution providing weakly parallel forward
102
  progress guarantees cannot be expected to make progress regardless of
103
  whether other threads make progress or not; however, blocking with
104
  forward progress guarantee delegation, as defined below, can be used to
105
  ensure that such threads of execution make progress
106
  eventually. — *end note*]
107
 
108
  Concurrent forward progress guarantees are stronger than parallel
109
  forward progress guarantees, which in turn are stronger than weakly
110
  parallel forward progress guarantees.
111
 
112
- [*Note 9*: For example, some kinds of synchronization between threads
113
- of execution may only make progress if the respective threads of
114
  execution provide parallel forward progress guarantees, but will fail to
115
  make progress under weakly parallel guarantees. — *end note*]
116
 
117
  When a thread of execution P is specified to *block with forward
118
  progress guarantee delegation* on the completion of a set S of threads
119
  of execution, then throughout the whole time of P being blocked on S,
120
  the implementation shall ensure that the forward progress guarantees
121
  provided by at least one thread of execution in S is at least as strong
122
  as P’s forward progress guarantees.
123
 
124
- [*Note 10*: It is unspecified which thread or threads of execution in S
125
  are chosen and for which number of execution steps. The strengthening is
126
  not permanent and not necessarily in place for the rest of the lifetime
127
  of the affected thread of execution. As long as P is blocked, the
128
  implementation has to eventually select and potentially strengthen a
129
  thread of execution in S. — *end note*]
130
 
131
  Once a thread of execution in S terminates, it is removed from S. Once S
132
  is empty, P is unblocked.
133
 
134
- [*Note 11*: A thread of execution B thus can temporarily provide an
135
  effectively stronger forward progress guarantee for a certain amount of
136
  time, due to a second thread of execution A being blocked on it with
137
  forward progress guarantee delegation. In turn, if B then blocks with
138
- forward progress guarantee delegation on C, this may also temporarily
139
  provide a stronger forward progress guarantee to C. — *end note*]
140
 
141
- [*Note 12*: If all threads of execution in S finish executing (e.g.,
142
  they terminate and do not use blocking synchronization incorrectly),
143
  then P’s execution of the operation that blocks with forward progress
144
  guarantee delegation will not result in P’s progress guarantee being
145
  effectively weakened. — *end note*]
146
 
147
- [*Note 13*: This does not remove any constraints regarding blocking
148
  synchronization for threads of execution providing parallel or weakly
149
  parallel forward progress guarantees because the implementation is not
150
  required to strengthen a particular thread of execution whose too-weak
151
  progress guarantee is preventing overall progress. — *end note*]
152
 
 
16
  [[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
17
  *lock-free executions*.
18
 
19
  - If there is only one thread that is not blocked [[defns.block]] in a
20
  standard library function, a lock-free execution in that thread shall
21
+ complete. \[*Note 2*: Concurrently executing threads might prevent
22
  progress of a lock-free execution. For example, this situation can
23
  occur with load-locked store-conditional implementations. This
24
  property is sometimes termed obstruction-free. — *end note*]
25
  - When one or more lock-free executions run concurrently, at least one
26
  should complete. \[*Note 3*: It is difficult for some implementations
27
  to provide absolute guarantees to this effect, since repeated and
28
+ particularly inopportune interference from other threads could prevent
29
  forward progress, e.g., by repeatedly stealing a cache line for
30
  unrelated purposes between load-locked and store-conditional
31
+ instructions. For implementations that follow this recommendation and
32
+ ensure that such effects cannot indefinitely delay progress under
33
+ expected operating conditions, such anomalies can therefore safely be
34
+ ignored by programmers. Outside this document, this property is
35
+ sometimes termed lock-free. — *end note*]
36
 
37
  During the execution of a thread of execution, each of the following is
38
  termed an *execution step*:
39
 
40
  - termination of the thread of execution,
 
46
  is considered to continuously execute execution steps while waiting for
47
  the condition that it blocks on to be satisfied.
48
 
49
  [*Example 1*: A library I/O function that blocks until the I/O
50
  operation is complete can be considered to continuously check whether
51
+ the operation is complete. Each such check consists of one or more
52
  execution steps, for example using observable behavior of the abstract
53
  machine. — *end example*]
54
 
55
  [*Note 4*: Because of this and the preceding requirement regarding what
56
  threads of execution have to perform eventually, it follows that no
 
65
  For a thread of execution providing *concurrent forward progress
66
  guarantees*, the implementation ensures that the thread will eventually
67
  make progress for as long as it has not terminated.
68
 
69
  [*Note 5*: This is required regardless of whether or not other threads
70
+ of execution (if any) have been or are making progress. To eventually
71
  fulfill this requirement means that this will happen in an unspecified
72
  but finite amount of time. — *end note*]
73
 
74
  It is *implementation-defined* whether the implementation-created thread
75
  of execution that executes `main` [[basic.start.main]] and the threads
76
  of execution created by `std::thread` [[thread.thread.class]] or
77
  `std::jthread` [[thread.jthread.class]] provide concurrent forward
78
+ progress guarantees. General-purpose implementations should provide
79
+ these guarantees.
 
 
80
 
81
  For a thread of execution providing *parallel forward progress
82
  guarantees*, the implementation is not required to ensure that the
83
  thread will eventually make progress if it has not yet executed any
84
  execution step; once this thread has executed a step, it provides
85
  concurrent forward progress guarantees.
86
 
87
+ [*Note 6*: This does not specify a requirement for when to start this
88
  thread of execution, which will typically be specified by the entity
89
  that creates this thread of execution. For example, a thread of
90
  execution that provides concurrent forward progress guarantees and
91
  executes tasks from a set of tasks in an arbitrary order, one after the
92
  other, satisfies the requirements of parallel forward progress for these
 
94
 
95
  For a thread of execution providing *weakly parallel forward progress
96
  guarantees*, the implementation does not ensure that the thread will
97
  eventually make progress.
98
 
99
+ [*Note 7*: Threads of execution providing weakly parallel forward
100
  progress guarantees cannot be expected to make progress regardless of
101
  whether other threads make progress or not; however, blocking with
102
  forward progress guarantee delegation, as defined below, can be used to
103
  ensure that such threads of execution make progress
104
  eventually. — *end note*]
105
 
106
  Concurrent forward progress guarantees are stronger than parallel
107
  forward progress guarantees, which in turn are stronger than weakly
108
  parallel forward progress guarantees.
109
 
110
+ [*Note 8*: For example, some kinds of synchronization between threads
111
+ of execution might only make progress if the respective threads of
112
  execution provide parallel forward progress guarantees, but will fail to
113
  make progress under weakly parallel guarantees. — *end note*]
114
 
115
  When a thread of execution P is specified to *block with forward
116
  progress guarantee delegation* on the completion of a set S of threads
117
  of execution, then throughout the whole time of P being blocked on S,
118
  the implementation shall ensure that the forward progress guarantees
119
  provided by at least one thread of execution in S is at least as strong
120
  as P’s forward progress guarantees.
121
 
122
+ [*Note 9*: It is unspecified which thread or threads of execution in S
123
  are chosen and for which number of execution steps. The strengthening is
124
  not permanent and not necessarily in place for the rest of the lifetime
125
  of the affected thread of execution. As long as P is blocked, the
126
  implementation has to eventually select and potentially strengthen a
127
  thread of execution in S. — *end note*]
128
 
129
  Once a thread of execution in S terminates, it is removed from S. Once S
130
  is empty, P is unblocked.
131
 
132
+ [*Note 10*: A thread of execution B thus can temporarily provide an
133
  effectively stronger forward progress guarantee for a certain amount of
134
  time, due to a second thread of execution A being blocked on it with
135
  forward progress guarantee delegation. In turn, if B then blocks with
136
+ forward progress guarantee delegation on C, this can also temporarily
137
  provide a stronger forward progress guarantee to C. — *end note*]
138
 
139
+ [*Note 11*: If all threads of execution in S finish executing (e.g.,
140
  they terminate and do not use blocking synchronization incorrectly),
141
  then P’s execution of the operation that blocks with forward progress
142
  guarantee delegation will not result in P’s progress guarantee being
143
  effectively weakened. — *end note*]
144
 
145
+ [*Note 12*: This does not remove any constraints regarding blocking
146
  synchronization for threads of execution providing parallel or weakly
147
  parallel forward progress guarantees because the implementation is not
148
  required to strengthen a particular thread of execution whose too-weak
149
  progress guarantee is preventing overall progress. — *end note*]
150