This moves the increment and decrement operators from detail::AtomicBase to
detail::AtomicBaseIncDec and moves the implementation of the assignment
operator into detail::AtomicBase. Additionally, this changes the integral
implementation to use mozilla::EnableIf for its specialization.
This moves the increment and decrement operators from detail::AtomicBase to
detail::AtomicBaseIncDec and moves the implementation of the assignment
operator into detail::AtomicBase. Additionally, this changes the integral
implementation to use mozilla::EnableIf for its specialization.
The C++ standard (29.6p20-22 in N3337) specifies limitations on the failure ordering
for atomic compare-and-exchange. Specifically, you can't pass memory_order_acq_rel or
memory_order_release. For the (T&, T, std::memory_order) version, which we use, the
standard specifies that the provided argument should be "lowered" to comply with the
above restrictions on the failure ordering (29.6p21).
However, it seems that some versions of GCC's <atomic> header don't follow the spec
for the generic versions of std::atomic<>, though they do follow the spec with the
appropriate specializations (bool, integer, and pointer) of std::atomic<>. This
results in mysterious failures when using atomic enums, as bug 888548 purports to
do, and ReleaseAcquire ordering.
Happily, we can work around this by using the more explicit version of
compare-and-exchange. I've chosen to add another member to AtomicOrderConstraints,
even though it'd be the same as LoadOrder. I feel explicitness is to be preferred
here.
