Title
atomic_ref<cv T> is not well-specified
Status
new
Section
[atomics.ref.generic.general]
Submitter
Casey Carter

Created on 2020-12-02.00:00:00 last changed 4 weeks ago

Messages

Date: 2020-12-15.00:00:00

[ 2020-12-19; Reflector prioritization ]

Set priority to 2 during reflector discussions.

Date: 2020-12-07.21:15:14

atomic_ref<T> requires only that its template parameter T is trivially copyable, which is not sufficient to implement many of the class template's member functions. Consider, for example:

int main() {
  static const int x = 42;
  std::atomic_ref<const int> meow{x};
  meow.store(0);
  return meow.load();
}

Since const int is trivially copyable, this is a well-formed C++20 program that returns 0. That said, the store call that mutates the value of a constant object is (a) not implementable with library technology, and (b) pure madness that violates the language semantics. atomic_ref::store should presumably require is_copy_assignable_v<T>, and other operations need to have their requirements audited as well. (Related: LWG 3012 made similar changes to atomic.)

As a related issue, volatile atomic<T> recently had its member functions deprecated when they are not lock-free. Presumably atomic_ref<volatile T> should require that atomic operations on T be lock-free for consistency.

Jonathan:

The last point is related to LWG 3417 (another case where we screwed up the volatile deprecations).

History
Date User Action Args
2020-12-19 18:47:42adminsetmessages: + msg11642
2020-12-02 00:00:00admincreate