MIME-Version: 1.0
References: <2muwyx6a5vojkg7iegknhnkcch3lfxptsxk7icwuh7szkvvu2y@vc3ukkfvnu6i>
 <CAPpHfdvucbQ9w7_eJYefUUp6w-WZUes+SRfq+GKfhukhs7kLqg@mail.gmail.com>
 <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>
In-Reply-To: <vhimanxfy2h5hlfxeaoxqak4bfdovy35tbrd7o2jq6q5e27mc6@6ntlvt2n3ltk>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sat, 8 Mar 2025 17:06:38 +0200
Message-ID: 
 <CAPpHfdtja4qxK5-T+RTdHki+sycbrZaP7==2CD4K+_b+dkUxNA@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdtja4qxK5-T%2BRTdHki%2BsycbrZaP7%3D%3D2CD4K%2B_b%2BdkUxNA%40mail.gmail.com>
Precedence: bulk

On Sat, Mar 8, 2025 at 3:41=E2=80=AFPM Andres Freund <andres@anarazel.de> w=
rote:
>
> 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 co=
uld be
> > ordered!  What their barriers guarantee is ordering between multiple me=
mory
> > operation, you can't order multiple writes if you don't have multiple
> > writes...  The synchronization in the C/C++ model is only established b=
etween
> > accesses of the same variable and there's no write in the case of a fai=
led
> > CAS, so there's nothing that could establish a release-acquire ordering=
.
> >
> > Unfortunately that model doesn't mesh well with barriers that aren't at=
tached
> > 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 w=
hat
> we ought to do is to redefine the barrier semantics to only imply an acqu=
ire
> 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.

------
Regards,
Alexander Korotkov
Supabase