ISO/IEC JTC1 SC22 WG21 N2783 = 08-0293 - 2008-09-18
Lawrence Crowl, Lawrence@Crowl.org, crowl@google.com
This paper collects several issues with the current atomics and provides proposed resolutions for them.
The description of memory_order values
could be read to imply acquire semantics when there was no load
and release semantics when there was no store.
The solution is to reorganize the specification
to be load and store centric
rather than memory_order value centric.
The term "consistent execution" is not well-defined. The solution is to reorganize the paragraph to avoid the term.
There were incorrect specifications of memory_order values.
These specifications have been corrected by editorial changes.
The current definition of atomics and list initialization do not support the syntax of aggregate initialization. (There was no requirement to support full aggregate initialization.) The issue is that explicit constructors are not applicable to copy-list-initialization. The solution is to remove the explicit qualifier. This solution is safe for all the reasons described in N2514 Implicit Conversion Operators for Atomics.
The constexpr value constructors had neither a body nor a textual definition. The solution is to add a textual definition.
There were incorrect specifications of memory_order values.
These specifications have been corrected by editorial changes.
The base document for these wording changes is N2723.
From LWG issue 818, edit paragraph 1 as follows.
The enumeration
memory_orderspecifies the detailed regular (non-atomic) memory synchronization order as defined inClause 1.7section 1.10 and may provide for operation ordering. Its enumerated values and their meanings are as follows:
- For
memory_order_relaxed,- no operation orders memory.
- For
memory_order_release,memory_order_acq_rel, andmemory_order_seq_cst,- a store operation performs a release operation on the affected memory location.
- For
memory_order_consume,- a load operation performs a consume operation on the affected memory location.
- For
memory_order_acquire,memory_order_acq_rel, andmemory_order_seq_cst,- a load operation performs an acquire operation on the affected memory location.
From LWG issue 818, remove table 136.
Table 136 — memory_order effectsElementMeaningmemory_order_relaxedthe operation does not order memorymemory_order_releasethe operation performs a release operation on the affected memory location, thus making regular memory writes visible to other threads through the atomic variable to which it is appliedmemory_order_acquirethe operation performs an acquire operation on the affected memory location, thus making regular memory writes in other threads released through the atomic variable to which it is applied visible to the current threadmemory_order_consumethe operation performs a consume operation on the affected memory location, thus making regular memory writes in other threads released through the atomic variable to which it is applied visible to the regular memory reads that are dependencies of this consume operation.memory_order_acq_relthe operation has both acquire and release semanticsmemory_order_seq_cstthe operation has both acquire and release semantics, and, in addition, has sequentially-consistent operation ordering
From LWG issue 818, edit paragraph 2 as follows.
TheTherememory_order_seq_cstoperations that load a value are acquire operations on the affected locations. Thememory_order_seq_cstoperations that store a value are release operations on the affected locations. In addition, in a consistent execution, theremust beis a single total order S on allmemory_order_seq_cstoperations, consistent with the happens before order and modification orders for all affected locations, such that eachmemory_order_seq_cstoperation observes either the last preceding modification according to this order S, or the result of an operation that is notmemory_order_seq_cst. [Note: 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. —end note]
For issue 845, within the synopsis edit as follows.
.... typedef struct atomic_bool { .... constexprexplicitatomic_bool(bool); .... typedef struct atomic_itype { .... constexprexplicitatomic_itype(integral); ....
For issue 845, edit paragraph 2 as follows.
The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexprexplicitvalue constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. They shall each support aggregate initialization syntax.
For issue 845, within the synopsis edit as follows.
.... typedef struct atomic_address { .... constexprexplicitatomic_address(void*); ....
For issue 845, edit paragraph 1 as follows.
The typeatomic_addressshall have standard layout. It shall have a trivial default constructor, a constexprexplicitvalue constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. It shall support aggregate initialization syntax.
For issue 845, within the synopsis edit as follows.
.... template <class T> struct atomic { .... constexprexplicitatomic(T); .... template <> struct atomic<integral> : atomic_itype { .... constexprexplicitatomic(integral); .... template <> struct atomic<T*> : atomic_address { .... constexprexplicitatomic(T*); ....
For issue 845, edit paragraph 2 as follows.
Specializations of theatomictemplate shall have a deleted copy constructor, a deleted copy assignment operator, and a constexprexplicitvalue constructor.
For issue LWG 846,
before the description of ...is_lock_free,
that is before paragraph 4,
add the following description.
constexpr A::A(C desired);
- Effects:
- Initializes the object with the value
desired. [Note: Construction is not atomic. —end note]