Re: pg_atomic_compare_exchange_*() and memory barriers

Hi,

On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:
> On Sat, Mar 8, 2025 at 3:41 PM Andres Freund <andres@anarazel.de> wrote:
> >
> > On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> > > 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...
> >
> > Adding a full barrier to failed CAS would be a rather large overhead,
> > undesirable in just about any sane algorithm. As a consequence, I think what
> > we ought to do is to redefine the barrier semantics to only imply an acquire
> > barrier in case CAS fails.
> 
> Thank you, I'm good with this solution.  Can I leave this on you?  I'm
> not feeling myself strong to word this correctly.

Not in the next ~four weeks. If you ping me afterwards, I can give it a go.

FWIW, I am fairly certain that any non-toy algorithm that requires a full
memory barrier instead of just an acquire in case of a CAS failure is chock
full of concurrency bugs.

Greetings,

Andres Freund