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
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?) |