public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Korotkov <[email protected]>
To: Andres Freund <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
Date: Fri, 13 Mar 2026 13:21:08 +0200
Message-ID: <CAPpHfds7unb9QT4v-Po1wGnC7=7zEaGBUL+QJDDgcinBO3KyfQ@mail.gmail.com> (raw)
In-Reply-To: <i6c5gvab3yu6a7ncofixch53b7tkvvwci5scvq6z3eulnkcg7u@4sv7wht4qz4c>
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>
On Sat, Mar 8, 2025 at 5:20 PM Andres Freund <[email protected]> wrote:
> On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:
> > On Sat, Mar 8, 2025 at 3:41 PM Andres Freund <[email protected]> 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
view thread (20+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
In-Reply-To: <CAPpHfds7unb9QT4v-Po1wGnC7=7zEaGBUL+QJDDgcinBO3KyfQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox