[intro.progress] - C++17 → C++20

Files changed (1) hide show

tmp/tmp7e9lab8v/{from.md → to.md} +37 -36

tmp/tmp7e9lab8v/{from.md → to.md} RENAMED Viewed

@@ -1,6 +1,6 @@
-### Forward progress <a id="intro.progress">[[intro.progress]]</a>
 The implementation may assume that any thread will eventually do one of
 the following:
 - terminate,
@@ -10,17 +10,17 @@ the following:
 [*Note 1*: This is intended to allow compiler transformations such as
 removal of empty loops, even when termination cannot be
 proven. — *end note*]
-Executions of atomic functions that are either defined to be lock-free (
-[[atomics.flag]]) or indicated as lock-free ([[atomics.lockfree]]) are
 *lock-free executions*.
-- If there is only one thread that is not blocked ([[defns.block]]) in
- a standard library function, a lock-free execution in that thread
- shall complete. \[*Note 2*: Concurrently executing threads may prevent
   progress of a lock-free execution. For example, this situation can
   occur with load-locked store-conditional implementations. This
   property is sometimes termed obstruction-free. — *end note*]
 - When one or more lock-free executions run concurrently, at least one
   should complete. \[*Note 3*: It is difficult for some implementations
@@ -40,13 +40,13 @@ termed an *execution step*:
 - termination of the thread of execution,
 - performing an access through a volatile glvalue, or
 - completion of a call to a library I/O function, a synchronization
   operation, or an atomic operation.
-An invocation of a standard library function that blocks (
-[[defns.block]]) is considered to continuously execute execution steps
-while waiting for the condition that it blocks on to be satisfied.
 [*Example 1*: A library I/O function that blocks until the I/O
 operation is complete can be considered to continuously check whether
 the operation is complete. Each such check might consist of one or more
 execution steps, for example using observable behavior of the abstract
@@ -70,16 +70,17 @@ make progress for as long as it has not terminated.
 of executions (if any) have been or are making progress. To eventually
 fulfill this requirement means that this will happen in an unspecified
 but finite amount of time. — *end note*]
 It is *implementation-defined* whether the implementation-created thread
-of execution that executes `main` ([[basic.start.main]]) and the
-threads of execution created by `std::thread` ([[thread.thread.class]])
-provide concurrent forward progress guarantees.
-[*Note 6*: General-purpose implementations are encouraged to provide
-these guarantees. — *end note*]
 For a thread of execution providing *parallel forward progress
 guarantees*, the implementation is not required to ensure that the
 thread will eventually make progress if it has not yet executed any
 execution step; once this thread has executed a step, it provides
@@ -111,38 +112,38 @@ parallel forward progress guarantees.
 [*Note 9*: For example, some kinds of synchronization between threads
 of execution may only make progress if the respective threads of
 execution provide parallel forward progress guarantees, but will fail to
 make progress under weakly parallel guarantees. — *end note*]
-When a thread of execution *P* is specified to *block with forward
-progress guarantee delegation* on the completion of a set *S* of threads
-of execution, then throughout the whole time of *P* being blocked on
-*S*, the implementation shall ensure that the forward progress
-guarantees provided by at least one thread of execution in *S* is at
-least as strong as *P*’s forward progress guarantees.
-[*Note 10*: It is unspecified which thread or threads of execution in
-*S* are chosen and for which number of execution steps. The
-strengthening is not permanent and not necessarily in place for the rest
-of the lifetime of the affected thread of execution. As long as *P* is
-blocked, the implementation has to eventually select and potentially
-strengthen a thread of execution in *S*. — *end note*]
-Once a thread of execution in *S* terminates, it is removed from *S*.
-Once *S* is empty, *P* is unblocked.
-[*Note 11*: A thread of execution *B* thus can temporarily provide an
 effectively stronger forward progress guarantee for a certain amount of
-time, due to a second thread of execution *A* being blocked on it with
-forward progress guarantee delegation. In turn, if *B* then blocks with
-forward progress guarantee delegation on *C*, this may also temporarily
-provide a stronger forward progress guarantee to *C*. — *end note*]
-[*Note 12*: If all threads of execution in *S* finish executing (e.g.,
 they terminate and do not use blocking synchronization incorrectly),
-then *P*’s execution of the operation that blocks with forward progress
-guarantee delegation will not result in *P*’s progress guarantee being
 effectively weakened. — *end note*]
 [*Note 13*: This does not remove any constraints regarding blocking
 synchronization for threads of execution providing parallel or weakly
 parallel forward progress guarantees because the implementation is not

+#### Forward progress <a id="intro.progress">[[intro.progress]]</a>
 The implementation may assume that any thread will eventually do one of
 the following:
 - terminate,
 [*Note 1*: This is intended to allow compiler transformations such as
 removal of empty loops, even when termination cannot be
 proven. — *end note*]
+Executions of atomic functions that are either defined to be lock-free
+[[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
 *lock-free executions*.
+- If there is only one thread that is not blocked [[defns.block]] in a
+  standard library function, a lock-free execution in that thread shall
+  complete. \[*Note 2*: Concurrently executing threads may prevent
   progress of a lock-free execution. For example, this situation can
   occur with load-locked store-conditional implementations. This
   property is sometimes termed obstruction-free. — *end note*]
 - When one or more lock-free executions run concurrently, at least one
   should complete. \[*Note 3*: It is difficult for some implementations
 - termination of the thread of execution,
 - performing an access through a volatile glvalue, or
 - completion of a call to a library I/O function, a synchronization
   operation, or an atomic operation.
+An invocation of a standard library function that blocks [[defns.block]]
+is considered to continuously execute execution steps while waiting for
+the condition that it blocks on to be satisfied.
 [*Example 1*: A library I/O function that blocks until the I/O
 operation is complete can be considered to continuously check whether
 the operation is complete. Each such check might consist of one or more
 execution steps, for example using observable behavior of the abstract
 of executions (if any) have been or are making progress. To eventually
 fulfill this requirement means that this will happen in an unspecified
 but finite amount of time. — *end note*]
 It is *implementation-defined* whether the implementation-created thread
+of execution that executes `main` [[basic.start.main]] and the threads
+of execution created by `std::thread` [[thread.thread.class]] or
+`std::jthread` [[thread.jthread.class]] provide concurrent forward
+progress guarantees.
+[*Note 6*: General-purpose implementations should provide these
+guarantees. — *end note*]
 For a thread of execution providing *parallel forward progress
 guarantees*, the implementation is not required to ensure that the
 thread will eventually make progress if it has not yet executed any
 execution step; once this thread has executed a step, it provides
 [*Note 9*: For example, some kinds of synchronization between threads
 of execution may only make progress if the respective threads of
 execution provide parallel forward progress guarantees, but will fail to
 make progress under weakly parallel guarantees. — *end note*]
+When a thread of execution P is specified to *block with forward
+progress guarantee delegation* on the completion of a set S of threads
+of execution, then throughout the whole time of P being blocked on S,
+the implementation shall ensure that the forward progress guarantees
+provided by at least one thread of execution in S is at least as strong
+as P’s forward progress guarantees.
+[*Note 10*: It is unspecified which thread or threads of execution in S
+are chosen and for which number of execution steps. The strengthening is
+not permanent and not necessarily in place for the rest of the lifetime
+of the affected thread of execution. As long as P is blocked, the
+implementation has to eventually select and potentially strengthen a
+thread of execution in S. — *end note*]
+Once a thread of execution in S terminates, it is removed from S. Once S
+is empty, P is unblocked.
+[*Note 11*: A thread of execution B thus can temporarily provide an
 effectively stronger forward progress guarantee for a certain amount of
+time, due to a second thread of execution A being blocked on it with
+forward progress guarantee delegation. In turn, if B then blocks with
+forward progress guarantee delegation on C, this may also temporarily
+provide a stronger forward progress guarantee to C. — *end note*]
+[*Note 12*: If all threads of execution in S finish executing (e.g.,
 they terminate and do not use blocking synchronization incorrectly),
+then P’s execution of the operation that blocks with forward progress
+guarantee delegation will not result in P’s progress guarantee being
 effectively weakened. — *end note*]
 [*Note 13*: This does not remove any constraints regarding blocking
 synchronization for threads of execution providing parallel or weakly
 parallel forward progress guarantees because the implementation is not

Diff to HTML by rtfpessoa