[atomics.order] - C++11 → C++14

Files changed (1) hide show

tmp/tmprj3swsmx/{from.md → to.md} +23 -57

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

@@ -40,16 +40,14 @@ orders for all affected locations, such that each `memory_order_seq_cst`
 operation *B* that loads a value from an atomic object *M* observes one
 of the following values:
 - the result of the last modification *A* of *M* that precedes *B* in
   *S*, if it exists, or
-- if *A* exists, the result of some modification of *M* in the visible
-  sequence of side effects with respect to *B* that is not
   `memory_order_seq_cst` and that does not happen before *A*, or
-- if *A* does not exist, the result of some modification of *M* in the
- visible sequence of side effects with respect to *B* that is not
-  `memory_order_seq_cst`.
 Although it is not explicitly required that *S* include locks, it can
 always be extended to an order that does include lock and unlock
 operations, since the ordering between those is already included in the
 “happens before” ordering.
@@ -71,63 +69,33 @@ modifies *M* and *B* takes its value, if there are
 `memory_order_seq_cst` fences *X* and *Y* such that *A* is sequenced
 before *X*, *Y* is sequenced before *B*, and *X* precedes *Y* in *S*,
 then *B* observes either the effects of *A* or a later modification of
 *M* in its modification order.
-For atomic operations *A* and *B* on an atomic object *M*, if there are
-`memory_order_seq_cst` fences `X` and `Y` such that *A* is sequenced
-before *X*, *Y* is sequenced before *B*, and *X* precedes *Y* in *S*,
-then *B* occurs later than *A* in the modification order of *M*.
 `memory_order_seq_cst` ensures sequential consistency only for a program
 that is free of data races and uses exclusively `memory_order_seq_cst`
 operations. Any use of weaker ordering will invalidate this guarantee
 unless extreme care is used. In particular, `memory_order_seq_cst`
 fences ensure a total order only for the fences themselves. Fences
 cannot, in general, be used to restore sequential consistency for atomic
 operations with weaker ordering specifications.
-An atomic store shall only store a value that has been computed from
-constants and program input values by a finite sequence of program
-evaluations, such that each evaluation observes the values of variables
-as computed by the last prior assignment in the sequence. The ordering
-of evaluations in this sequence shall be such that:
-- if an evaluation *B* observes a value computed by *A* in a different
-  thread, then *B* does not happen before *A*, and
-- if an evaluation *A* is included in the sequence, then every
-  evaluation that assigns to the same variable and happens before *A* is
-  included.
-The second requirement disallows “out-of-thin-air” or “speculative”
-stores of atomics when relaxed atomics are used. Since unordered
-operations are involved, evaluations may appear in this sequence out of
-thread order. For example, with `x` and `y` initially zero,
-``` cpp
-// Thread 1:
-r1 = y.load(memory_order_relaxed);
-x.store(r1, memory_order_relaxed);
-```
-``` cpp
-// Thread 2:
-r2 = x.load(memory_order_relaxed);
-y.store(42, memory_order_relaxed);
-```
-is allowed to produce `r1 = r2 = 42`. The sequence of evaluations
-justifying this consists of:
-``` cpp
-y.store(42, memory_order_relaxed);
-r1 = y.load(memory_order_relaxed);
-x.store(r1, memory_order_relaxed);
-r2 = x.load(memory_order_relaxed);
-```
-On the other hand,
 ``` cpp
 // Thread 1:
 r1 = y.load(memory_order_relaxed);
 x.store(r1, memory_order_relaxed);
@@ -137,32 +105,30 @@ x.store(r1, memory_order_relaxed);
 // Thread 2:
 r2 = x.load(memory_order_relaxed);
 y.store(r2, memory_order_relaxed);
 ```
-may not produce `r1 = r2 = 42`, since there is no sequence of
-evaluations that results in the computation of 42. In the absence of
-“relaxed” operations and read-modify-write operations with weaker than
-`memory_order_acq_rel` ordering, the second requirement has no impact.
-The requirements do allow `r1 == r2 == 42` in the following example,
-with `x` and `y` initially zero:
 ``` cpp
 // Thread 1:
 r1 = x.load(memory_order_relaxed);
-if (r1 == 42) y.store(r1, memory_order_relaxed);
 ```
 ``` cpp
 // Thread 2:
 r2 = y.load(memory_order_relaxed);
 if (r2 == 42) x.store(42, memory_order_relaxed);
 ```
-However, implementations should not allow such behavior.
 Atomic read-modify-write operations shall always read the last value (in
 the modification order) written before the write associated with the
 read-modify-write operation.
 Implementations should make atomic stores visible to atomic loads within

 operation *B* that loads a value from an atomic object *M* observes one
 of the following values:
 - the result of the last modification *A* of *M* that precedes *B* in
   *S*, if it exists, or
+- if *A* exists, the result of some modification of *M* that is not
   `memory_order_seq_cst` and that does not happen before *A*, or
+- if *A* does not exist, the result of some modification of *M* that is
+  not `memory_order_seq_cst`.
 Although it is not explicitly required that *S* include locks, it can
 always be extended to an order that does include lock and unlock
 operations, since the ordering between those is already included in the
 “happens before” ordering.
 `memory_order_seq_cst` fences *X* and *Y* such that *A* is sequenced
 before *X*, *Y* is sequenced before *B*, and *X* precedes *Y* in *S*,
 then *B* observes either the effects of *A* or a later modification of
 *M* in its modification order.
+For atomic modifications *A* and *B* of an atomic object *M*, *B* occurs
+later than *A* in the modification order of *M* if:
+- there is a `memory_order_seq_cst` fence *X* such that *A* is sequenced
+  before *X*, and *X* precedes *B* in *S*, or
+- there is a `memory_order_seq_cst` fence *Y* such that *Y* is sequenced
+  before *B*, and *A* precedes *Y* in *S*, or
+- there are `memory_order_seq_cst` fences *X* and *Y* such that *A* is
+  sequenced before *X*, *Y* is sequenced before *B*, and *X* precedes
+  *Y* in *S*.
 `memory_order_seq_cst` ensures sequential consistency only for a program
 that is free of data races and uses exclusively `memory_order_seq_cst`
 operations. Any use of weaker ordering will invalidate this guarantee
 unless extreme care is used. In particular, `memory_order_seq_cst`
 fences ensure a total order only for the fences themselves. Fences
 cannot, in general, be used to restore sequential consistency for atomic
 operations with weaker ordering specifications.
+Implementations should ensure that no “out-of-thin-air” values are
+computed that circularly depend on their own computation.
+For example, with `x` and `y` initially zero,
 ``` cpp
 // Thread 1:
 r1 = y.load(memory_order_relaxed);
 x.store(r1, memory_order_relaxed);
 // Thread 2:
 r2 = x.load(memory_order_relaxed);
 y.store(r2, memory_order_relaxed);
 ```
+should not produce `r1 == r2 == 42`, since the store of 42 to `y` is
+only possible if the store to `x` stores `42`, which circularly depends
+on the store to `y` storing `42`. Note that without this restriction,
+such an execution is possible.
+The recommendation similarly disallows `r1 == r2 == 42` in the following
+example, with `x` and `y` again initially zero:
 ``` cpp
 // Thread 1:
 r1 = x.load(memory_order_relaxed);
+if (r1 == 42) y.store(42, memory_order_relaxed);
 ```
 ``` cpp
 // Thread 2:
 r2 = y.load(memory_order_relaxed);
 if (r2 == 42) x.store(42, memory_order_relaxed);
 ```
 Atomic read-modify-write operations shall always read the last value (in
 the modification order) written before the write associated with the
 read-modify-write operation.
 Implementations should make atomic stores visible to atomic loads within

Diff to HTML by rtfpessoa