Re: pg_atomic_compare_exchange_*() and memory barriers

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