Collected Issues with Atomics

ISO/IEC JTC1 SC22 WG21 N2783 = 08-0293 - 2008-09-18

Lawrence Crowl, Lawrence@Crowl.org, crowl@google.com

Issues

This paper collects several issues with the current atomics and provides proposed resolutions for them.

LWG 818 wording for memory ordering

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.

LWG 845 atomics cannot support aggregate initialization

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.

LWG 846 no definition for constructor

The constexpr value constructors had neither a body nor a textual definition. The solution is to add a textual definition.

LWG 864 defect in atomic wording

There were incorrect specifications of memory_order values. These specifications have been corrected by editorial changes.

Wording

The base document for these wording changes is N2723.

29.1 Order and Consistency [atomics.order]

From LWG issue 818, edit paragraph 1 as follows.

The enumeration memory_order specifies the detailed regular (non-atomic) memory synchronization order as defined in Clause 1.7 section 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, and memory_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, and memory_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 effects
ElementMeaning
memory_order_relaxed the operation does not order memory
memory_order_release the 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 applied
memory_order_acquire the 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 thread
memory_order_consume the 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_rel the operation has both acquire and release semantics
memory_order_seq_cst the operation has both acquire and release semantics, and, in addition, has sequentially-consistent operation ordering

From LWG issue 818, edit paragraph 2 as follows.

The memory_order_seq_cst operations that load a value are acquire operations on the affected locations. The memory_order_seq_cst operations that store a value are release operations on the affected locations. In addition, in a consistent execution, there There must be is a single total order S on all memory_order_seq_cst operations, consistent with the happens before order and modification orders for all affected locations, such that each memory_order_seq_cst operation observes either the last preceding modification according to this order S, or the result of an operation that is not memory_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]

29.3.1 Integral Types [atomics.types.integral]

For issue 845, within the synopsis edit as follows.


....
typedef struct atomic_bool {
....
  constexpr explicit atomic_bool(bool);
....
typedef struct atomic_itype {
....
  constexpr explicit atomic_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 constexpr explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. They shall each support aggregate initialization syntax.

29.3.2 Address Type [atomics.types.address]

For issue 845, within the synopsis edit as follows.


....
typedef struct atomic_address {
....
  constexpr explicit atomic_address(void*);
....

For issue 845, edit paragraph 1 as follows.

The type atomic_address shall have standard layout. It shall have a trivial default constructor, a constexpr explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. It shall support aggregate initialization syntax.

29.3.3 Generic Types [atomics.types.generic]

For issue 845, within the synopsis edit as follows.


....
template <class T> struct atomic {
....
  constexpr explicit atomic(T);
....
template <> struct atomic<integral> : atomic_itype {
....
  constexpr explicit atomic(integral);
....
template <> struct atomic<T*> : atomic_address {
....
  constexpr explicit atomic(T*);
....

For issue 845, edit paragraph 2 as follows.

Specializations of the atomic template shall have a deleted copy constructor, a deleted copy assignment operator, and a constexpr explicit value constructor.

29.4 Operations on Types [atomics.types.operations]

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]