Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Strange asm generated by GCC...
Date: Mon, 23 Dec 2024 13:20:33 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vkck71$1cp7c$1@dont-email.me>
References: <vk2ek2$33ckv$3@dont-email.me> <vk4ahk$3i1bs$1@dont-email.me>
 <At6cnfsh1ZzpB_v6nZ2dnZfqn_adnZ2d@supernews.com>
 <vkamjt$11jv0$2@dont-email.me> <vkamr2$11jv0$3@dont-email.me>
 <h0ydnQ-XeaVIvfT6nZ2dnZfqnPednZ2d@supernews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 23 Dec 2024 22:20:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f0e44193300486c78d7a7f6e740e8e90";
	logging-data="1467628"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ob1IICzomr/hlSrYZcYXiqatR4HA7LWY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4MmTtA/+BmdUFCXdkobT/ClPY1U=
Content-Language: en-US
In-Reply-To: <h0ydnQ-XeaVIvfT6nZ2dnZfqnPednZ2d@supernews.com>
Bytes: 2764

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.