Feedback-ID: id4a34324:Fastmail
Date: Sat, 8 Mar 2025 08:02:41 -0500
From: Andres Freund <andres@anarazel.de>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_atomic_compare_exchange_*() and memory barriers
Message-ID: <6ybtypq2v3kvskiqj7izl2rmfrcluilsmbobtpylcnp7moa7vq@2q3cplokvcza>
References: 
 <CAPpHfdudejddHLLw=Uk_7pZ=1g2SZXfwubSgmWUhJ7fBUtR9rg@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAPpHfdv5y63auGJ_QGJ7VDA1z7cS+YcfUtgAxGit5c2EApbMBA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/6ybtypq2v3kvskiqj7izl2rmfrcluilsmbobtpylcnp7moa7vq%402q3cplokvcza>
Precedence: bulk

Hi,

On 2025-03-08 14:12:13 +0200, Alexander Korotkov wrote:
> I'm not an expert in formal specifications of memory models.  But I'm quite
> surprised we're discussing whether memory barrier on compare-exchange
> failure might matter.  For me at least the fact
> that __atomic_compare_exchange_n() have failure_memorder argument is a
> quite an evidence of that.

I wasn't trying to say that the failure memory order doesn't matter, just that
an *acquire* barrier might be strong enough in the failure case if you look at
it from the POV of C++/C11's memory model. The docs for
__atomic_compare_exchange_n say:

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#index-_005f_005fatomic_005fcompare_005fexchange_005fn

> Otherwise, false is returned and memory is affected according to
> failure_memorder. This memory order cannot be __ATOMIC_RELEASE nor
> __ATOMIC_ACQ_REL. It also cannot be a stronger order than that specified by
> success_memorder.

Note that the generated code you showed *did* unconditionally execute the load
with acquire semantics.

Which means that that one can argue that this is *NOT* a compiler bug.