[intro.multithread] - C++11 → C++14

Files changed (1) hide show

tmp/tmpqoi6pm84/{from.md → to.md} +61 -24

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

@@ -15,16 +15,41 @@ execution can be viewed as an interleaving of all its threads. However,
 some kinds of atomic operations, for example, allow executions
 inconsistent with a simple interleaving, as described below. Under a
 freestanding implementation, it is *implementation-defined* whether a
 program can have more than one thread of execution.
 Implementations should ensure that all unblocked threads eventually make
 progress. Standard library functions may silently block on I/O or locks.
 Factors in the execution environment, including externally-imposed
 thread priorities, may prevent an implementation from making certain
 guarantees of forward progress.
 The value of an object visible to a thread *T* at a particular point is
 the initial value of the object, a value assigned to the object by *T*,
 or a value assigned to the object by another thread, according to the
 rules below. In some cases, there may instead be undefined behavior.
 Much of this section is motivated by the desire to support atomic
@@ -174,19 +199,15 @@ or undefined. This states that operations on ordinary objects are not
 visibly reordered. This is not actually detectable without data races,
 but it is necessary to ensure that data races, as defined below, and
 with suitable restrictions on the use of atomics, correspond to data
 races in a simple interleaved (sequentially consistent) execution.
-The *visible sequence of side effects* on an atomic object *M*, with
-respect to a value computation *B* of *M*, is a maximal contiguous
-sub-sequence of side effects in the modification order of *M*, where the
-first side effect is visible with respect to *B*, and for every side
-effect, it is not the case that *B* happens before it. The value of an
-atomic object *M*, as determined by evaluation *B*, shall be the value
-stored by some operation in the visible sequence of *M* with respect to
-*B*. It can be shown that the visible sequence of side effects of a
-value computation is unique given the coherence requirements below.
 If an operation *A* that modifies an atomic object *M* happens before an
 operation *B* that modifies *M*, then *A* shall be earlier than *B* in
 the modification order of *M*. This requirement is known as write-write
 coherence.
@@ -197,13 +218,13 @@ value computation *B* of *M*, and *A* takes its value from a side effect
 stored by *X* or the value stored by a side effect *Y* on *M*, where *Y*
 follows *X* in the modification order of *M*. This requirement is known
 as read-read coherence.
 If a value computation *A* of an atomic object *M* happens before an
-operation *B* on *M*, then *A* shall take its value from a side effect
-*X* on *M*, where *X* precedes *B* in the modification order of *M*.
-This requirement is known as read-write coherence.
 If a side effect *X* on an atomic object *M* happens before a value
 computation *B* of *M*, then the evaluation *B* shall take its value
 from *X* or from a side effect *Y* that follows *X* in the modification
 order of *M*. This requirement is known as write-read coherence.
@@ -211,22 +232,29 @@ order of *M*. This requirement is known as write-read coherence.
 The four preceding coherence requirements effectively disallow compiler
 reordering of atomic operations to a single object, even if both
 operations are relaxed loads. This effectively makes the cache coherence
 guarantee provided by most hardware available to C++atomic operations.
-The visible sequence of side effects depends on the “happens before”
-relation, which depends on the values observed by loads of atomics,
-which we are restricting here. The intended reading is that there must
-exist an association of atomic loads with modifications they observe
-that, together with suitably chosen modification orders and the “happens
-before” relation derived as described above, satisfy the resulting
-constraints as imposed here.
 The execution of a program contains a *data race* if it contains two
-conflicting actions in different threads, at least one of which is not
-atomic, and neither happens before the other. Any such data race results
-in undefined behavior. It can be shown that programs that correctly use
 mutexes and `memory_order_seq_cst` operations to prevent all data races
 and use no other synchronization operations behave as if the operations
 executed by their constituent threads were simply interleaved, with each
 value computation of an object being taken from the last side effect on
 that object in that interleaving. This is normally referred to as
@@ -235,20 +263,29 @@ programs, and data-race-free programs cannot observe most program
 transformations that do not change single-threaded program semantics. In
 fact, most single-threaded program transformations continue to be
 allowed, since any program that behaves differently as a result must
 perform an undefined operation.
 Compiler transformations that introduce assignments to a potentially
 shared memory location that would not be modified by the abstract
 machine are generally precluded by this standard, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
 of atomic loads in cases in which the atomics in question may alias is
-also generally precluded, since this may violate the “visible sequence”
-rules.
 Transformations that introduce a speculative read of a potentially
 shared memory location may not preserve the semantics of the C++program
 as defined in this standard, since they potentially introduce a data
 race. However, they are typically valid in the context of an optimizing

 some kinds of atomic operations, for example, allow executions
 inconsistent with a simple interleaving, as described below. Under a
 freestanding implementation, it is *implementation-defined* whether a
 program can have more than one thread of execution.
+A signal handler that is executed as a result of a call to the `raise`
+function belongs to the same thread of execution as the call to the
+`raise` function. Otherwise it is unspecified which thread of execution
+contains a signal handler invocation.
 Implementations should ensure that all unblocked threads eventually make
 progress. Standard library functions may silently block on I/O or locks.
 Factors in the execution environment, including externally-imposed
 thread priorities, may prevent an implementation from making certain
 guarantees of forward progress.
+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 unblocked thread, a lock-free execution in that
+  thread shall complete. 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.
+- When one or more lock-free executions run concurrently, at least one
+  should complete. It is difficult for some implementations to provide
+  absolute guarantees to this effect, since repeated and particularly
+  inopportune interference from other threads may prevent forward
+  progress, e.g., by repeatedly stealing a cache line for unrelated
+  purposes between load-locked and store-conditional instructions.
+  Implementations should ensure that such effects cannot indefinitely
+  delay progress under expected operating conditions, and that such
+  anomalies can therefore safely be ignored by programmers. Outside this
+  International Standard, this property is sometimes termed lock-free.
 The value of an object visible to a thread *T* at a particular point is
 the initial value of the object, a value assigned to the object by *T*,
 or a value assigned to the object by another thread, according to the
 rules below. In some cases, there may instead be undefined behavior.
 Much of this section is motivated by the desire to support atomic
 visibly reordered. This is not actually detectable without data races,
 but it is necessary to ensure that data races, as defined below, and
 with suitable restrictions on the use of atomics, correspond to data
 races in a simple interleaved (sequentially consistent) execution.
+The value of an atomic object *M*, as determined by evaluation *B*,
+shall be the value stored by some side effect *A* that modifies *M*,
+where *B* does not happen before *A*. The set of such side effects is
+also restricted by the rest of the rules described here, and in
+particular, by the coherence requirements below.
 If an operation *A* that modifies an atomic object *M* happens before an
 operation *B* that modifies *M*, then *A* shall be earlier than *B* in
 the modification order of *M*. This requirement is known as write-write
 coherence.
 stored by *X* or the value stored by a side effect *Y* on *M*, where *Y*
 follows *X* in the modification order of *M*. This requirement is known
 as read-read coherence.
 If a value computation *A* of an atomic object *M* happens before an
+operation *B* that modifies *M*, then *A* shall take its value from a
+side effect *X* on *M*, where *X* precedes *B* in the modification order
+of *M*. This requirement is known as read-write coherence.
 If a side effect *X* on an atomic object *M* happens before a value
 computation *B* of *M*, then the evaluation *B* shall take its value
 from *X* or from a side effect *Y* that follows *X* in the modification
 order of *M*. This requirement is known as write-read coherence.
 The four preceding coherence requirements effectively disallow compiler
 reordering of atomic operations to a single object, even if both
 operations are relaxed loads. This effectively makes the cache coherence
 guarantee provided by most hardware available to C++atomic operations.
+The value observed by a load of an atomic depends on the “happens
+before” relation, which depends on the values observed by loads of
+atomics. The intended reading is that there must exist an association of
+atomic loads with modifications they observe that, together with
+suitably chosen modification orders and the “happens before” relation
+derived as described above, satisfy the resulting constraints as imposed
+here.
+Two actions are *potentially concurrent* if
+- they are performed by different threads, or
+- they are unsequenced, and at least one is performed by a signal
+  handler.
 The execution of a program contains a *data race* if it contains two
+potentially concurrent conflicting actions, at least one of which is not
+atomic, and neither happens before the other, except for the special
+case for signal handlers described below. Any such data race results in
+undefined behavior. It can be shown that programs that correctly use
 mutexes and `memory_order_seq_cst` operations to prevent all data races
 and use no other synchronization operations behave as if the operations
 executed by their constituent threads were simply interleaved, with each
 value computation of an object being taken from the last side effect on
 that object in that interleaving. This is normally referred to as
 transformations that do not change single-threaded program semantics. In
 fact, most single-threaded program transformations continue to be
 allowed, since any program that behaves differently as a result must
 perform an undefined operation.
+Two accesses to the same object of type `volatile sig_atomic_t` do not
+result in a data race if both occur in the same thread, even if one or
+more occurs in a signal handler. For each signal handler invocation,
+evaluations performed by the thread invoking a signal handler can be
+divided into two groups *A* and *B*, such that no evaluations in *B*
+happen before evaluations in *A*, and the evaluations of such
+`volatile sig_atomic_t` objects take values as though all evaluations in
+*A* happened before the execution of the signal handler and the
+execution of the signal handler happened before all evaluations in *B*.
 Compiler transformations that introduce assignments to a potentially
 shared memory location that would not be modified by the abstract
 machine are generally precluded by this standard, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
 of atomic loads in cases in which the atomics in question may alias is
+also generally precluded, since this may violate the coherence rules.
 Transformations that introduce a speculative read of a potentially
 shared memory location may not preserve the semantics of the C++program
 as defined in this standard, since they potentially introduce a data
 race. However, they are typically valid in the context of an optimizing

Diff to HTML by rtfpessoa