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
. [P0528r1] applied EWG guidance and simply added
wording directing implementations to ensure that the desired behavior occur. At
SG1’s request this paper follows EWG’s guidance but uses different wording.
1. Edit History
1.1. r2 → r3
In Rapperswil, CWG suggested various wording updates to the paper.
1.2. r1 → r2
In Jacksonville, SG1 supported the paper but suggested an alternate way to approach the wording than the one EWG proposed in Albuquerque: don’t talk about contents of the memory, but rather discuss the value representation to describe compare-and-exchange. This paper follows SG1’s guidance and offers different wording, with the intent that the semantics be equivalent. EWG reviewed the updated wording an voted to support it and forward to Core.
1.3. 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
types [atomics.types.operations], edit ❡17 and
onwards as follows:
bool compare_exchange_weak ( T & expected , T desired , memory_order success , memory_order failure ) volatile noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order success , memory_order failure ) noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order success , memory_order failure ) volatile noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order success , memory_order failure ) noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; bool compare_exchange_weak ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) volatile noexcept ; bool compare_exchange_strong ( T & expected , T desired , memory_order order = memory_order :: seq_cst ) noexcept ;
❡17:
Requires: The
argument shall not be
failure nor
memory_order :: release .
memory_order :: acq_rel
❡18:
Effects: Retrieves the value in
. It then atomically compares the
expected contents of the memoryvalue representation of the value pointed to byfor equality with that previously retrieved from
this , and if true, replaces the
expected contents of the memoryvalue pointed to bywith 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
memory_order :: relaxed contents of the memoryvalue in
expected areis replaced by the valueread from the memorypointed to byduring 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
❡19:
Returns: The result of the comparison.
❡20:
[Note:
For example, the effect of
on objects without padding bits 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]
❡21:
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
❡22:
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]
❡23:
[Note:
Under cases where theTheand
memcpy semantics of the compare-and-exchange operations apply, the outcome might be
memcmp may result infailed comparisons for values that compare equal withif the underlying type has
operator == padding bits,trap bits,or alternate representations of the same value. Notably, on implementations conforming to ISO/IEC/IEEE 60559, floating-pointand
- 0.0 will not compare equal with
+ 0.0 but will compare equal with
memcmp , and NaNs with the same payload will compare equal with
operator == but will not compare equal with
memcmp .
operator == —end note]
[Note:
Because compare-and-exchange acts on an object’s value representation, padding bits that never participate in the object’s value representation are ignored.
As a consequence, the following code is guaranteed to avoid spurious failure:
struct padded { char clank = 0x42 ; // Padding here. unsigned biff = 0xC0DEFEFE ; }; atomic < padded > pad = ATOMIC_VAR_INIT ({}); bool zap () { padded expected , desired { 0 , 0 }; return pad . compare_exchange_strong ( expected , desired ); } —end note]
[Note:
For a union with bits that participate in the value representation of some members but not others, compare-and-exchange might always fail. This is because such padding bits have an indeteminate value when they do not participate in the value representation of the active member.
As a consequence, the following code is not guaranteed to ever succeed:
union pony { double celestia = 0. ; short luna ; // padded }; atomic < pony > princesses = ATOMIC_VAR_INIT ({}); bool party ( pony desired ) { pony expected ; return princesses . compare_exchange_strong ( expected , desired ); } —end note]