Re: Strange asm generated by GCC...

On 12/23/2024 12:35 AM, aph@littlepinkcloud.invalid wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 12/22/2024 7:49 PM, Chris M. Thomasson wrote:

On 12/21/2024 2:37 AM, aph@littlepinkcloud.invalid wrote:

jseigh <jseigh_es00@xemaps.com> wrote:

 

I don't see anything that forces a store memory barrier
on all the fail paths.  I could be missing something.

>
Why would there be one? If the store does not take place, there's no
need for a memory barrier because there's no store for anyone to
synchronize with. The only effect of a failed weak CAS is a load. If
you really need a store on failure because of its side effect you can
always add one.

>
Iirc, the membars for the success and failure can be "useful" for
popping from a lock-free stack. Wrt the C++ API the CAS can give you the
updated value on a failure. So, there is a load. Depending on what you
are doing, it might require an acquire.

>
Loading the head of the lock-free stack would be an acquire at the start
of the CAS loop. The CAS can use relaxed for the success and an acquire
for the failure.

 The para I'm quoting:
 

I don't see anything that forces a store memory barrier

 We were talking about the *store barrier* associated with the store.
There is acquire ordering, regardless of the success or failure of the
store.

Wrt a traditional lock-free stack, I think the store can use relaxed for the success path of a CAS.