31 Atomic operations library [atomics]

It is possible to have an access to an atomic object A race with its construction, for example by communicating the address of the just-constructed object A to another thread via memory_­order​::​relaxed operations on a suitable atomic pointer variable, and then immediately accessing A in the receiving thread.

This results in undefined behavior.

The value of is_­always_­lock_­free is consistent with the value of the corresponding ATOMIC_­..._­LOCK_­FREE macro, if defined.

The return value of the is_­lock_­free member function is consistent with the value of is_­always_­lock_­free for the same type.

For example, the effect of compare_­exchange_­strong on objects without padding bits ([basic.types]) is

if (memcmp(this, &expected, sizeof(*this)) == 0)
  memcpy(this, &desired, sizeof(*this));
else
  memcpy(expected, this, sizeof(*this));

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.

Under cases where the memcpy and memcmp semantics of the compare-and-exchange operations apply, the outcome might be failed comparisons for values that compare equal with operator== if the value representation has trap bits or alternate representations of the same value.

Notably, on implementations conforming to ISO/IEC/IEEE 60559, floating-point -0.0 and +0.0 will not compare equal with memcmp but will compare equal with operator==, and NaNs with the same payload will compare equal with memcmp but will not compare equal with operator==.

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 = {};

bool zap() {
  padded expected, desired{0, 0};
  return pad.compare_exchange_strong(expected, desired);
}

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 indeterminate 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 = {};

bool party(pony desired) {
  pony expected;
  return princesses.compare_exchange_strong(expected, desired);
}