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: James Hunter <james.hunter.pg@gmail.com>
Date: Mon, 24 Mar 2025 19:08:20 -0700
Message-ID: 
 <CAJVSvF4pOd+Nxjc28pAtgrtszNiUkJOpmj0TncLpmgwrhDKoEw@mail.gmail.com>
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
To: Andres Freund <andres@anarazel.de>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 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/CAJVSvF4pOd%2BNxjc28pAtgrtszNiUkJOpmj0TncLpmgwrhDKoEw%40mail.gmail.com>
Precedence: bulk

On Sat, Mar 8, 2025 at 7:21=E2=80=AFAM Andres Freund <andres@anarazel.de> w=
rote:
>
> FWIW, I am fairly certain that any non-toy algorithm that requires a full
> memory barrier instead of just an acquire in case of a CAS failure is cho=
ck
> full of concurrency bugs.

Yeah -- off the top of my head, I can think of only two CAS patterns:
(1) retry the CAS until success (in which case the memory semantics of
a CAS failure don't matter); or (2) whoever wins the CAS is
responsible for doing some work. But, in (2), there's no reason to
expect that the "winner" has *completed* the work, so the memory
semantics of a CAS failure don't matter, since you need some other way
to say that the work has been completed.

Barriers are useful for seqlocks [1], which (IIRC) is the same
technique PostgreSQL uses for PG_STAT_BEGIN_{read,WRITE}_ACTIVITY. But
that's when you check the control (sequence) variable both before and
*after* touching the data it protects.

James

[1] https://en.wikipedia.org/wiki/Seqlock