Hi,
On 2025-03-08 14:12:13 +0200, Alexander Korotkov wrote:
> I'm not an expert in formal specifications of memory models. But I'm quite
> surprised we're discussing whether memory barrier on compare-exchange
> failure might matter. For me at least the fact
> that __atomic_compare_exchange_n() have failure_memorder argument is a
> quite an evidence of that.
I wasn't trying to say that the failure memory order doesn't matter, just that
an *acquire* barrier might be strong enough in the failure case if you look at
it from the POV of C++/C11's memory model. The docs for
__atomic_compare_exchange_n say:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#index-_005f_005fatomic_005fcompare_005fexchange_005fn
> Otherwise, false is returned and memory is affected according to
> failure_memorder. This memory order cannot be __ATOMIC_RELEASE nor
> __ATOMIC_ACQ_REL. It also cannot be a stronger order than that specified by
> success_memorder.
Note that the generated code you showed *did* unconditionally execute the load
with acquire semantics.
Which means that that one can argue that this is *NOT* a compiler bug.
From the C/C++ standard atomics model it doesn't make sense to say that a
failed CAS has release semantics, as there simply isn't a write that could be
ordered! What their barriers guarantee is ordering between multiple memory
operation, you can't order multiple writes if you don't have multiple
writes... The synchronization in the C/C++ model is only established between
accesses of the same variable and there's no write in the case of a failed
CAS, so there's nothing that could establish a release-acquire ordering.
Unfortunately that model doesn't mesh well with barriers that aren't attached
to read/modify operations. Which is what we ended up with...
Greetings,
Andres Freund
