This issue has been discussed by the authors at every recent Standards meetings, yet a full solution has been elusive despite helpful proposals. We believe that this proposal can fix this oft-encountered problem once and for all.
[P0528r0] details extensive background on this problem (not repeated here),
and proposed standardizing a trait,
, and using it on
. This paper applies EWG guidance and simply adds a
note.
1. Edit History
1.1. r0 → r1
In Albuquerque, EWG voted to make the padding bits of
and the incoming
value of
have a consistent value for the purposes of read/modify/write
atomic operations?
Purposefully not addressed in this paper:
-
with padding bitsunion -
Types with trap representations
2. Proposed Wording
In Operations on atomic types [atomics.types.operations], insert a new paragraph after the note in ❡1:
[Note: Many operations are volatile-qualified. The "volatile as device register" semantics have not changed in the standard. This qualification means that volatility is preserved when applying these operations to volatile objects. It does not mean that operations on non-volatile objects become volatile. —end note]
Atomic operations, both through
and free-functions, can be performed on types
atomic < T > which contain bits that never participate in the object’s representation. In such cases an implementation shall ensure that initialization, assignment, store, exchange, and read-modify-write operations replace bits which never participate in the object’s representation with an implementation-defined value. A compatible implementation-defined value shall be used for compare-and-exchange operations' copy of the
T value.
expected As a consequence, the following code is guaranteed to avoid spurious failure:
struct padded { char c = 0x42 ; // Padding here. unsigned i = 0xC0DEFEFE ; }; atomic < padded > pad = ATOMIC_VAR_INIT ({}); bool success () { padded expected , desired { 0 , 0 }; return pad . compare_exchange_strong ( expected , desired ); } [Note:
Types which contain bits that sometimes participate in the object’s representation, such as a
containing a type with padding bits and a type without, may always fail compare-and-exchange when these bits are not participating in the object’s representation because they have an indeterminate value. Such a program is ill-formed, no diagnostic required.
union —end note]
Edit ❡17 and onwards as follows:
Requires: The
argument shall not be
failure nor
memory_order :: release .
memory_order :: acq_rel Effects: Retrieves the value in
. Bits in the retrieved value which never participate in the object’s representation are set to a value compatible to that previously stored in the atomic object. It then atomically compares the contents of the memory pointed to by
expected for equality with that previously retrieved from
this , and if true, replaces the contents of the memory pointed to by
expected with that in
this . If and only if the comparison is true, memory is affected according to the value of
desired , and if the comparison is false, memory is affected according to the value of
success . When only one
failure argument is supplied, the value of
memory_order is
success , and the value of
order is
failure except that a value of
order shall be replaced by the value
memory_order :: acq_rel and a value of
memory_order :: acquire shall be replaced by the value
memory_order :: release . If and only if the comparison is false then, after the atomic operation, the contents of the memory in
memory_order :: relaxed are replaced by the value read from the memory pointed to by
expected during the atomic comparison. If the operation returns
this true
, these operations are atomic read-modify-write operations on the memory pointed to by. Otherwise, these operations are atomic load operations on that memory.
this Returns: The result of the comparison.
[Note:
For example, the effect of
is
compare_exchange_strong if ( memcmp ( this , & expected , sizeof ( * this )) == 0 ) memcpy ( this , & desired , sizeof ( * this )); else memcpy ( expected , this , sizeof ( * this )); —end note]
[Example:
The expected use of the compare-and-exchange operations is as follows. The compare-and-exchange operations will update
when another iteration of the loop is needed.
expected expected = current . load (); do { desired = function ( expected ); } while ( ! current . compare_exchange_weak ( expected , desired )); —end example]
[Example:
Because the expected value is updated only on failure, code releasing the memory containing the
value on success will work. E.g. list head insertion will act atomically and would not introduce a data race in the following code:
expected do { p -> next = head ; // make new list node point to the current head } while ( ! head . compare_exchange_weak ( p -> next , p )); // try to insert —end example]
Implementations should ensure that weak compare-and-exchange operations do not consistently return
false
unless either the atomic object has value different fromor there are concurrent modifications to the atomic object.
expected Remarks: A weak compare-and-exchange operation may fail spuriously. That is, even when the contents of memory referred to by
and
expected are equal, it may return
this false
and store back tothe same memory contents that were originally there.
expected [Note:
This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g., load-locked store-conditional machines. A consequence of spurious failure is that nearly all uses of weak compare-and-exchange will be in a loop. When a compare-and-exchange is in a loop, the weak version will yield better performance on some platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the strong one is preferable.
—end note]
[Note:
The
and
memcpy semantics of the compare-and-exchange operations may result in failed comparisons for values that compare equal with
memcmp if the underlying type has padding bits which sometimes participate in the object’s representation , trap bits, or alternate representations of the same value other than those caused by padding bits which never participate in the object’s representation .
operator == —end note]