[cpp-threads] Review of N2995 and resulting email threads

[Peter Dimov]

Paul E. McKenney wrote:
...
>>> [Note: Atomic and locking objects are not trivially
>>> copyable [3.9], so executions that access atomic
>>> or locking objects as non-atomic objects, for example
>>> through an array of character type, will have undefined
>>> behaviour - end note]

...

> OK, so your point is that there are the following additional cases?

My main point is that I don't believe that the note is correct, pedantically 
speaking, as I don't see why reading the storage bytes of an atomic object 
without a data race would invoke undefined behavior. But there are some 
practical considerations as well.

Note that, for example, 29.5.1/2 says that atomic integral types have 
standard layout and support aggregate initialization, and 29.5.1/5 
encourages them to have the same size as the underlying integral type. I 
can't think of any reason to mandate standard layout _unless_ the intent is 
for atomic_int to be struct { int }; there is nothing to be gained from the 
standard layout requirement otherwise.

And if atomic_int is, in fact, struct { int }, standard layout and 9.2/17 
allow one to read and write the underlying int via a 
reinterpret_cast<int&>( v ).

All this is fully supported by the memory model. As long as there's no race, 
everything is fine and well.