| 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: | Whole Thread | Raw Message | 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?) |