This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3409. Too lax description of `atomic_ref<T>::required_alignment`

Section: 33.5.7.2 [atomics.ref.ops] Status: New Submitter: Andrey Semashev Opened: 2020-02-27 Last modified: 2020-09-06

Priority: 3

View all issues with New status.

Discussion:

N4849 33.5.7.2 [atomics.ref.ops]/1 describes `atomic_ref<T>::required_alignment` constant as follows:

> The alignment required for an object to be referenced by an atomic reference, which is at least `alignof(T)`.

This wording allows for an implementation to always define `required_alignment` to be equal to `alignof(T)` and implement atomic operations using locking, even if a lock-free implementation is possible at a higher alignment. For example, on x86-64, `atomic_ref<complex<double>>` could be lock-free only when the referred object is aligned to 16 bytes, but the above definition allows an implementation to define `required_alignment` to 8 and use locking.

The note in 33.5.7.2 [atomics.ref.ops]/2 does mention that lock-free operations may require higher alignment, but it does not provide guidance to the implementations so that `required_alignment` reflects alignment required for lock-free operations, if possible, and not just minimum alignment required for any kind of implementation.

The suggested resolution is to change the wording so that it is clear that `required_alignment` indicates the alignment required for lock-free implementation, if one is possible, or `alignof(T)` otherwise.

Further, the note in 33.5.7.2 [atomics.ref.ops]/2 contains this sentence:

> Further, whether operations on an `atomic_ref` are lock-free could depend on the alignment of the referenced object.

This sentence is misleading, because according to `is_lock_free()` definition in 33.5.7.2 [atomics.ref.ops]/4, the lock-free property is not allowed to depend on the alignment of a particular referenced object (`is_lock_free()` must return `true` or `false` if operations on all objects of the given type `T` are lock-free or not). In other words, `atomic_ref` can only refer to an object aligned at least to `required_alignment` and its lock-free capability cannot depend on the actual runtime alignment of the object.

To avoid the confusion, I propose to remove the sentence. The rest of the note can stay intact. However, this second edit is less important than the first one and can be omitted in case of disagreement.

[2020-04-04 Issue Prioritization]

Priority to 3 after reflector discussion.

Proposed resolution:

This wording is relative to N4849.

1. Modify 33.5.7.2 [atomics.ref.ops] as indicated:

   >     static constexpr size_t required_alignment;

   > > -1- Let `A` be t The alignment required for an object to be referenced by an atomic reference, which is at least `alignof(T)`so that `is_always_lock_free` is `true`. If there is no such alignment or `A` is less than `alignof(T)`, `required_alignment` equals `alignof(T)`. Otherwise, `required_alignment` equals `A`.

   > > -2- [Note: Hardware could require an object referenced by an `atomic_ref` to have stricter alignment (6.7.6 [basic.align]) than other objects of type `T`. Further, whether operations on an `atomic_ref` are lock-free could depend on the alignment of the referenced object. For example, lock-free operations on `std::complex<double>` could be supported only if aligned to `2*alignof(double)`. — end note]