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

Files changed (1) hide show

tmp/tmpunh6wn27/{from.md → to.md} +41 -73

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

@@ -72,13 +72,13 @@ namespace std {
   bool atomic_compare_exchange_weak(atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_strong(volatile atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_strong(atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_weak_explicit(volatile atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
-  bool atomic_compare_exchange_weak_explicit(atomic-type*, T*, T.
     memory_order, memory_order) noexcept;
-  bool atomic_compare)exchange_strong_explicit(volatile atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
   bool atomic_compare_exchange_strong_explicit(atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
   // [atomics.types.operations.templ], templated operations on atomic types
@@ -233,16 +233,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.
@@ -264,63 +262,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);
@@ -330,32 +298,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
@@ -555,11 +521,11 @@ defined in  [[atomics.types.operations]].
 Specializations and instantiations of the `atomic` template shall have a
 deleted copy constructor, a deleted copy assignment operator, and a
 constexpr value constructor.
-There shall be full specializations of the `atomic` template for the
 integral types `char`, `signed char`, `unsigned char`, `short`,
 `unsigned short`, `int`, `unsigned int`, `long`, `unsigned long`,
 `long long`, `unsigned long long`, `char16_t`, `char32_t`, `wchar_t`,
 and any other types needed by the typedefs in the header `<cstdint>`.
 For each integral type *integral*, the specialization `atomic<integral>`
@@ -579,11 +545,11 @@ default constructors, and trivial destructors. They shall each support
 aggregate initialization syntax.
 There shall be named types corresponding to the integral specializations
 of `atomic`, as specified in Table  [[tab:atomics.integral]], and a
 named type `atomic_bool` corresponding to the specified `atomic<bool>`.
-Each named type is a either typedef to the corresponding specialization
 or a base class of the corresponding specialization. If it is a base
 class, it shall support the same member functions as the corresponding
 specialization.
 There shall be atomic typedefs corresponding to the typedefs in the
@@ -640,19 +606,17 @@ kind. The specific instances are defined in [[atomics.types.generic]],
 [[atomics.types.operations.pointer]].
 In the following operation definitions:
 - an *A* refers to one of the atomic types.
-- a *C* refers to its corresponding non-atomic type. The
-  `atomic_address` atomic type corresponds to the `void*` non-atomic
-  type.
 - an *M* refers to type of the other argument for arithmetic operations.
   For integral atomic types, *M* is *C*. For atomic address types, *M*
   is `std::ptrdiff_t`.
-- the free functions not ending in `_explicit` have the semantics of
-  their corresponding `_explicit` with `memory_order` arguments of
-  `memory_order_seq_cst`.
 Many operations are volatile-qualified. The “volatile as device
 register” semantics have not changed in the standard. This qualification
 means that volatility is preserved when applying these operations to
 volatile objects. It does not mean that operations on non-volatile
@@ -1000,18 +964,22 @@ The `atomic_flag` type shall have standard layout. It shall have a
 trivial default constructor, a deleted copy constructor, a deleted copy
 assignment operator, and a trivial destructor.
 The macro `ATOMIC_FLAG_INIT` shall be defined in such a way that it can
 be used to initialize an object of type `atomic_flag` to the clear
-state. For a static-duration object, that initialization shall be
-static. It is unspecified whether an uninitialized `atomic_flag` object
-has an initial state of set or clear.
 ``` cpp
 atomic_flag guard = ATOMIC_FLAG_INIT;
 ```
 ``` cpp
 bool atomic_flag_test_and_set(volatile atomic_flag* object) noexcept;
 bool atomic_flag_test_and_set(atomic_flag* object) noexcept;
 bool atomic_flag_test_and_set_explicit(volatile atomic_flag* object, memory_order order) noexcept;
 bool atomic_flag_test_and_set_explicit(atomic_flag* object, memory_order order) noexcept;
@@ -1034,12 +1002,12 @@ void atomic_flag_clear_explicit(volatile atomic_flag *object, memory_order order
 void atomic_flag_clear_explicit(atomic_flag* object, memory_order order) noexcept;
 void atomic_flag::clear(memory_order order = memory_order_seq_cst) volatile noexcept;
 void atomic_flag::clear(memory_order order = memory_order_seq_cst) noexcept;
 ```
-*Requires:* The `order` argument shall not be `memory_order_acquire` or
-`memory_order_acq_rel`.
 *Effects:* Atomically sets the value pointed to by `object` or by `this`
 to false. Memory is affected according to the value of `order`.
 ## Fences <a id="atomics.fences">[[atomics.fences]]</a>
@@ -1086,11 +1054,11 @@ extern "C" void atomic_thread_fence(memory_order order) noexcept;
 ``` cpp
 extern "C" void atomic_signal_fence(memory_order order) noexcept;
 ```
-*Effects:* equivalent to `atomic_thread_fence(order)`, except that the
 resulting ordering constraints are established only between a thread and
 a signal handler executed in the same thread.
 *Note:* `atomic_signal_fence` can be used to specify the order in which
 actions performed by the thread become visible to the signal handler.

   bool atomic_compare_exchange_weak(atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_strong(volatile atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_strong(atomic-type*, T*, T) noexcept;
   bool atomic_compare_exchange_weak_explicit(volatile atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
+  bool atomic_compare_exchange_weak_explicit(atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
+  bool atomic_compare_exchange_strong_explicit(volatile atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
   bool atomic_compare_exchange_strong_explicit(atomic-type*, T*, T,
     memory_order, memory_order) noexcept;
   // [atomics.types.operations.templ], templated operations on atomic types
 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
 Specializations and instantiations of the `atomic` template shall have a
 deleted copy constructor, a deleted copy assignment operator, and a
 constexpr value constructor.
+There shall be explicit specializations of the `atomic` template for the
 integral types `char`, `signed char`, `unsigned char`, `short`,
 `unsigned short`, `int`, `unsigned int`, `long`, `unsigned long`,
 `long long`, `unsigned long long`, `char16_t`, `char32_t`, `wchar_t`,
 and any other types needed by the typedefs in the header `<cstdint>`.
 For each integral type *integral*, the specialization `atomic<integral>`
 aggregate initialization syntax.
 There shall be named types corresponding to the integral specializations
 of `atomic`, as specified in Table  [[tab:atomics.integral]], and a
 named type `atomic_bool` corresponding to the specified `atomic<bool>`.
+Each named type is either a typedef to the corresponding specialization
 or a base class of the corresponding specialization. If it is a base
 class, it shall support the same member functions as the corresponding
 specialization.
 There shall be atomic typedefs corresponding to the typedefs in the
 [[atomics.types.operations.pointer]].
 In the following operation definitions:
 - an *A* refers to one of the atomic types.
+- a *C* refers to its corresponding non-atomic type.
 - an *M* refers to type of the other argument for arithmetic operations.
   For integral atomic types, *M* is *C*. For atomic address types, *M*
   is `std::ptrdiff_t`.
+- the non-member functions not ending in `_explicit` have the semantics
+ of their corresponding `_explicit` functions with `memory_order`
+ arguments of `memory_order_seq_cst`.
 Many operations are volatile-qualified. The “volatile as device
 register” semantics have not changed in the standard. This qualification
 means that volatility is preserved when applying these operations to
 volatile objects. It does not mean that operations on non-volatile
 trivial default constructor, a deleted copy constructor, a deleted copy
 assignment operator, and a trivial destructor.
 The macro `ATOMIC_FLAG_INIT` shall be defined in such a way that it can
 be used to initialize an object of type `atomic_flag` to the clear
+state. The macro can be used in the form:
 ``` cpp
 atomic_flag guard = ATOMIC_FLAG_INIT;
 ```
+It is unspecified whether the macro can be used in other initialization
+contexts. For a complete static-duration object, that initialization
+shall be static. Unless initialized with `ATOMIC_FLAG_INIT`, it is
+unspecified whether an `atomic_flag` object has an initial state of set
+or clear.
 ``` cpp
 bool atomic_flag_test_and_set(volatile atomic_flag* object) noexcept;
 bool atomic_flag_test_and_set(atomic_flag* object) noexcept;
 bool atomic_flag_test_and_set_explicit(volatile atomic_flag* object, memory_order order) noexcept;
 bool atomic_flag_test_and_set_explicit(atomic_flag* object, memory_order order) noexcept;
 void atomic_flag_clear_explicit(atomic_flag* object, memory_order order) noexcept;
 void atomic_flag::clear(memory_order order = memory_order_seq_cst) volatile noexcept;
 void atomic_flag::clear(memory_order order = memory_order_seq_cst) noexcept;
 ```
+*Requires:* The `order` argument shall not be `memory_order_consume`,
+`memory_order_acquire`, nor `memory_order_acq_rel`.
 *Effects:* Atomically sets the value pointed to by `object` or by `this`
 to false. Memory is affected according to the value of `order`.
 ## Fences <a id="atomics.fences">[[atomics.fences]]</a>
 ``` cpp
 extern "C" void atomic_signal_fence(memory_order order) noexcept;
 ```
+*Effects:* Equivalent to `atomic_thread_fence(order)`, except that the
 resulting ordering constraints are established only between a thread and
 a signal handler executed in the same thread.
 *Note:* `atomic_signal_fence` can be used to specify the order in which
 actions performed by the thread become visible to the signal handler.

Diff to HTML by rtfpessoa