Re: pg_atomic_compare_exchange_*() and memory barriers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
Date: 2025-03-08 13:41:24
Message-ID: vhimanxfy2h5hlfxeaoxqak4bfdovy35tbrd7o2jq6q5e27mc6@6ntlvt2n3ltk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Vatsa 2025-03-08 15:04:40 Re: Clarification on Role Access Rights to Table Indexes
Previous Message Andrew Dunstan 2025-03-08 13:11:18 Buildfarm coverage planning (was: what's going on with lapwing?)