MIME-Version: 1.0
References: <oc4iicdkwyhdf5o5vbwsl7jdlqnds37xtf27wuxvhy3abxoo6i@4ek3xp5j6niy>
 <CAPpHfdvp=_1NRF4YFFp9Oii7mRR5V4b-C2aukbuLQjWMjynYrw@mail.gmail.com>
 <aw3hirtizbn42fkl57bjeafzws3b2bvhknimbxyoi23i43sajb@i65p2ubb6zte>
 <CAPpHfdvp3vNVp5_Rx1RtwLqhjbzzUxwkqzvsh=1E3A+iePvWBg@mail.gmail.com>
 <vwtct75cykxo3rxjipye2bfvkaftncps4ycdock5vbvnwqtte5@h2hklzn36ckm>
 <CAPpHfduxVxkZpCaYRv_whvNyPxCTSyEgXR02sbo=mhGF0MDQEg@mail.gmail.com>
 <CAPpHfdv5y63auGJ_QGJ7VDA1z7cS+YcfUtgAxGit5c2EApbMBA@mail.gmail.com>
 <6ybtypq2v3kvskiqj7izl2rmfrcluilsmbobtpylcnp7moa7vq@2q3cplokvcza>
 <vhimanxfy2h5hlfxeaoxqak4bfdovy35tbrd7o2jq6q5e27mc6@6ntlvt2n3ltk>
 <CAPpHfdtja4qxK5-T+RTdHki+sycbrZaP7==2CD4K+_b+dkUxNA@mail.gmail.com>
 <i6c5gvab3yu6a7ncofixch53b7tkvvwci5scvq6z3eulnkcg7u@4sv7wht4qz4c>
In-Reply-To: <i6c5gvab3yu6a7ncofixch53b7tkvvwci5scvq6z3eulnkcg7u@4sv7wht4qz4c>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Fri, 13 Mar 2026 13:21:08 +0200
Message-ID: 
 <CAPpHfds7unb9QT4v-Po1wGnC7=7zEaGBUL+QJDDgcinBO3KyfQ@mail.gmail.com>
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000008f1a0a064ce611a1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfds7unb9QT4v-Po1wGnC7%3D7zEaGBUL%2BQJDDgcinBO3KyfQ%40mail.gmail.com>
Precedence: bulk

--0000000000008f1a0a064ce611a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 8, 2025 at 5:20=E2=80=AFPM Andres Freund <andres@anarazel.de> w=
rote:
> On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:
> > On Sat, Mar 8, 2025 at 3:41=E2=80=AFPM Andres Freund <andres@anarazel.d=
e> 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.

It has been more than a year.  Probably not perfect moment again.  But
could you, please, revise that comment?

------
Regards,
Alexander Korotkov
Supabase

--0000000000008f1a0a064ce611a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Mar 8, 2025 at 5:20=E2=80=AFPM Andres Freund &lt;<=
a href=3D"mailto:andres@anarazel.de">andres@anarazel.de</a>&gt; wrote:<br>&=
gt; On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:<br>&gt; &gt; On=
 Sat, Mar 8, 2025 at 3:41=E2=80=AFPM Andres Freund &lt;<a href=3D"mailto:an=
dres@anarazel.de">andres@anarazel.de</a>&gt; wrote:<br>&gt; &gt; &gt;<br>&g=
t; &gt; &gt; On 2025-03-08 08:02:41 -0500, Andres Freund wrote:<br>&gt; &gt=
; &gt; &gt; From the C/C++ standard atomics model it doesn&#39;t make sense=
 to say that a<br>&gt; &gt; &gt; &gt; failed CAS has release semantics, as =
there simply isn&#39;t a write that could be<br>&gt; &gt; &gt; &gt; ordered=
!=C2=A0 What their barriers guarantee is ordering between multiple memory<b=
r>&gt; &gt; &gt; &gt; operation, you can&#39;t order multiple writes if you=
 don&#39;t have multiple<br>&gt; &gt; &gt; &gt; writes...=C2=A0 The synchro=
nization in the C/C++ model is only established between<br>&gt; &gt; &gt; &=
gt; accesses of the same variable and there&#39;s no write in the case of a=
 failed<br>&gt; &gt; &gt; &gt; CAS, so there&#39;s nothing that could estab=
lish a release-acquire ordering.<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &=
gt; Unfortunately that model doesn&#39;t mesh well with barriers that aren&=
#39;t attached<br>&gt; &gt; &gt; &gt; to read/modify operations. Which is w=
hat we ended up with...<br>&gt; &gt; &gt;<br>&gt; &gt; &gt; Adding a full b=
arrier to failed CAS would be a rather large overhead,<br>&gt; &gt; &gt; un=
desirable in just about any sane algorithm. As a consequence, I think what<=
br>&gt; &gt; &gt; we ought to do is to redefine the barrier semantics to on=
ly imply an acquire<br>&gt; &gt; &gt; barrier in case CAS fails.<br>&gt; &g=
t;<br>&gt; &gt; Thank you, I&#39;m good with this solution.=C2=A0 Can I lea=
ve this on you?=C2=A0 I&#39;m<br>&gt; &gt; not feeling myself strong to wor=
d this correctly.<br>&gt;<br>&gt; Not in the next ~four weeks. If you ping =
me afterwards, I can give it a go.<br><br>It has been more than a year.=C2=
=A0 Probably not perfect moment again.=C2=A0 But could you, please, revise =
that comment?<br><br>------<br>Regards,<br>Alexander Korotkov<br>Supabase</=
div>

--0000000000008f1a0a064ce611a1--