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

### 777. Atomics Library Issue

Section: 31.8.2 [atomics.types.operations] Status: CD1 Submitter: Lawrence Crowl Opened: 2008-01-21 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [atomics.types.operations].

View all other issues in [atomics.types.operations].

View all issues with CD1 status.

Discussion:

The load functions are defined as

>     C atomic_load(volatile A* object);
>     C atomic_load_explicit(volatile A* object, memory_order);
>     C A::load(memory_order order = memory_order_seq_cst) volatile;

which prevents their use in `const` contexts.

[ post Bellevue Peter adds: ]

> Issue 777 suggests making `atomic_load` operate on `const` objects. There is a subtle point here. Atomic loads do not generally write to the object, except potentially for the `memory_order_seq_cst` constraint. Depending on the architecture, a dummy write with the same value may be required to be issued by the atomic load to maintain sequential consistency. This, in turn, may make the following code:

> >     const atomic_int x{};

> >     int main()
> >     {
> >       x.load();
> >     }

> dump core under a straightforward implementation that puts const objects in a read-only section.

> There are ways to sidestep the problem, but it needs to be considered.

> The tradeoff is between making the data member of the atomic types mutable and requiring the user to explicitly mark atomic members as mutable, as is already the case with mutexes.

Proposed resolution:

Add the `const` qualifier to `*object` and `*this`.

>     C atomic_load(const volatile A* object);
>     C atomic_load_explicit(const volatile A* object, memory_order);
>     C A::load(memory_order order = memory_order_seq_cst) const volatile;