[atomics.order] - C++23 → Trunk

Files changed (1) hide show

tmp/tmpeq9h5hkn/{from.md → to.md} +20 -25

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

@@ -1,11 +1,11 @@
 ### Order and consistency <a id="atomics.order">[[atomics.order]]</a>
 ``` cpp
 namespace std {
   enum class memory_order : unspecified {
-    relaxed, consume, acquire, release, acq_rel, seq_cst
   };
 }
 ```
 The enumeration `memory_order` specifies the detailed regular
@@ -15,21 +15,15 @@ enumerated values and their meanings are as follows:
 - `memory_order::relaxed`: no operation orders memory.
 - `memory_order::release`, `memory_order::acq_rel`, and
   `memory_order::seq_cst`: a store operation performs a release
   operation on the affected memory location.
-- `memory_order::consume`: a load operation performs a consume operation
-  on the affected memory location. \[*Note 1*: Prefer
-  `memory_order::acquire`, which provides stronger guarantees than
-  `memory_order::consume`. Implementations have found it infeasible to
-  provide performance better than that of `memory_order::acquire`.
-  Specification revisions are under consideration. — *end note*]
 - `memory_order::acquire`, `memory_order::acq_rel`, and
   `memory_order::seq_cst`: a load operation performs an acquire
   operation on the affected memory location.
-[*Note 2*: Atomic operations specifying `memory_order::relaxed` are
 relaxed with respect to memory ordering. Implementations must still
 guarantee that any given atomic access to a particular atomic object be
 indivisible with respect to all other atomic accesses to that
 object. — *end note*]
@@ -64,35 +58,35 @@ S:
 - if a `memory_order::seq_cst` fence X happens before A and B is a
   `memory_order::seq_cst` operation, then X precedes B in S; and
 - if a `memory_order::seq_cst` fence X happens before A and B happens
   before a `memory_order::seq_cst` fence Y, then X precedes Y in S.
-[*Note 3*: This definition ensures that S is consistent with the
 modification order of any atomic object M. It also ensures that a
 `memory_order::seq_cst` load A of M gets its value either from the last
 modification of M that precedes A in S or from some
 non-`memory_order::seq_cst` modification of M that does not happen
 before any modification of M that precedes A in S. — *end note*]
-[*Note 4*: We do not require that S be consistent with “happens before”
 [[intro.races]]. This allows more efficient implementation of
 `memory_order::acquire` and `memory_order::release` on some machine
 architectures. It can produce surprising results when these are mixed
 with `memory_order::seq_cst` accesses. — *end note*]
-[*Note 5*: `memory_order::seq_cst` ensures sequential consistency only
 for a program that is free of data races and uses exclusively
 `memory_order::seq_cst` atomic operations. Any use of weaker ordering
 will invalidate this guarantee unless extreme care is used. In many
 cases, `memory_order::seq_cst` atomic operations are reorderable with
 respect to other atomic operations performed by the same
 thread. — *end note*]
 Implementations should ensure that no “out-of-thin-air” values are
 computed that circularly depend on their own computation.
-[*Note 6*:
 For example, with `x` and `y` initially zero,
 ``` cpp
 // Thread 1:
@@ -111,11 +105,11 @@ 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.
 — *end note*]
-[*Note 7*:
 The recommendation similarly disallows `r1 == r2 == 42` in the following
 example, with `x` and `y` again initially zero:
 ``` cpp
@@ -134,18 +128,19 @@ 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
-a reasonable amount of time.
-``` cpp
-template<class T>
-  T kill_dependency(T y) noexcept;
-```
-*Effects:* The argument does not carry a dependency to the return
-value [[intro.multithread]].
-*Returns:* `y`.

 ### Order and consistency <a id="atomics.order">[[atomics.order]]</a>
 ``` cpp
 namespace std {
   enum class memory_order : unspecified {
+    relaxed = 0, acquire = 2, release = 3, acq_rel = 4, seq_cst = 5
   };
 }
 ```
 The enumeration `memory_order` specifies the detailed regular
 - `memory_order::relaxed`: no operation orders memory.
 - `memory_order::release`, `memory_order::acq_rel`, and
   `memory_order::seq_cst`: a store operation performs a release
   operation on the affected memory location.
 - `memory_order::acquire`, `memory_order::acq_rel`, and
   `memory_order::seq_cst`: a load operation performs an acquire
   operation on the affected memory location.
+[*Note 1*: Atomic operations specifying `memory_order::relaxed` are
 relaxed with respect to memory ordering. Implementations must still
 guarantee that any given atomic access to a particular atomic object be
 indivisible with respect to all other atomic accesses to that
 object. — *end note*]
 - if a `memory_order::seq_cst` fence X happens before A and B is a
   `memory_order::seq_cst` operation, then X precedes B in S; and
 - if a `memory_order::seq_cst` fence X happens before A and B happens
   before a `memory_order::seq_cst` fence Y, then X precedes Y in S.
+[*Note 2*: This definition ensures that S is consistent with the
 modification order of any atomic object M. It also ensures that a
 `memory_order::seq_cst` load A of M gets its value either from the last
 modification of M that precedes A in S or from some
 non-`memory_order::seq_cst` modification of M that does not happen
 before any modification of M that precedes A in S. — *end note*]
+[*Note 3*: We do not require that S be consistent with “happens before”
 [[intro.races]]. This allows more efficient implementation of
 `memory_order::acquire` and `memory_order::release` on some machine
 architectures. It can produce surprising results when these are mixed
 with `memory_order::seq_cst` accesses. — *end note*]
+[*Note 4*: `memory_order::seq_cst` ensures sequential consistency only
 for a program that is free of data races and uses exclusively
 `memory_order::seq_cst` atomic operations. Any use of weaker ordering
 will invalidate this guarantee unless extreme care is used. In many
 cases, `memory_order::seq_cst` atomic operations are reorderable with
 respect to other atomic operations performed by the same
 thread. — *end note*]
 Implementations should ensure that no “out-of-thin-air” values are
 computed that circularly depend on their own computation.
+[*Note 5*:
 For example, with `x` and `y` initially zero,
 ``` cpp
 // Thread 1:
 which circularly depends on the store to `y` storing `42`. Note that
 without this restriction, such an execution is possible.
 — *end note*]
+[*Note 6*:
 The recommendation similarly disallows `r1 == r2 == 42` in the following
 example, with `x` and `y` again initially zero:
 ``` cpp
 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.
+An *atomic modify-write operation* is an atomic read-modify-write
+operation with weaker synchronization requirements as specified in
+[[atomics.fences]].
+[*Note 7*: The intent is for atomic modify-write operations to be
+implemented using mechanisms that are not ordered, in hardware, by the
+implementation of acquire fences. No other semantic or hardware property
+(e.g., that the mechanism is a far atomic operation) is
+implied. — *end note*]
+*Recommended practice:* The implementation should make atomic stores
+visible to atomic loads, and atomic loads should observe atomic stores,
+within a reasonable amount of time.

Diff to HTML by rtfpessoa