Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Memory ordering
Date: Wed, 18 Dec 2024 18:48:05 -0800
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <vk01h4$2ihnf$1@dont-email.me>
References: <vfono1$14l9r$1@dont-email.me> <vh4530$2mar5$1@dont-email.me>
 <-rKdnTO4LdoWXKj6nZ2dnZfqnPWdnZ2d@supernews.com>
 <vh5t5b$312cl$2@dont-email.me>
 <5yqdnU9eL_Y_GKv6nZ2dnZfqn_GdnZ2d@supernews.com>
 <2024Nov15.082512@mips.complang.tuwien.ac.at> <vh7ak1$3cm56$1@dont-email.me>
 <20241115152459.00004c86@yahoo.com> <vh8bn7$3j6ql$1@dont-email.me>
 <vhb2dc$73fe$1@dont-email.me> <vhct2q$lk1b$2@dont-email.me>
 <2024Nov17.161752@mips.complang.tuwien.ac.at> <vhh16e$1lp5h$1@dont-email.me>
 <2024Dec3.100144@mips.complang.tuwien.ac.at> <vin2rp$3ofc$1@dont-email.me>
 <3aa9f0a3d3dde86193abb1c01e52d03a@www.novabbs.org>
 <jwvser449xz.fsf-monnier+comp.arch@gnu.org> <vipv2t$v57m$1@dont-email.me>
 <virlki$1fhli$1@dont-email.me> <vis85o$1k2um$1@dont-email.me>
 <vjq76k$1aj88$1@dont-email.me> <vjrr3m$1nppo$1@dont-email.me>
 <vjsnlj$1t7j9$2@dont-email.me> <vjuchf$294oo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Dec 2024 03:48:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d7ca23497301f77098352327da5c83f3";
	logging-data="2705135"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1//tNyiriNbtaxwRDk+MFr/tM/BonbQ8s4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0fUShMrtZLJbytfATYyCM2smJhA=
Content-Language: en-US
In-Reply-To: <vjuchf$294oo$1@dont-email.me>
Bytes: 3120

On 12/18/2024 3:43 AM, jseigh wrote:
> On 12/17/24 15:41, Chris M. Thomasson wrote:
>>
>> Agreed. Humm... The CAS is interesting to me.
>>
>> atomic_compare_exchange_weak
>> atomic_compare_exchange_strong
>>
>> The weak one can fail spuriously... Akin to LL/SC in a sense?
> 
> Most likely LL/SC in the implementation.  If you are calling
> cas in a loop, then the weak form will be safe, it will just
> retry.  The strong form is if you are not in a loop and the
> cas emulation code has extra logic to filter out spurious
> failures and retry internally.

I know to use the "strong" version for certain state machines. Where a 
CAS failure actually means the comparands are different.

>>
>> atomic_compare_exchange_weak_explicit
>> atomic_compare_exchange_strong_explicit
>>
>> A membar for the success path and one for the failure path. Oh that's 
>> fun. Sometimes I think its better to use relaxed for all of the 
>> atomics and use explicit barriers ala atomic_thread_fence for the 
>> order. Well, that is more in line with the SPARC way of doing 
>> things... ;^)
>>
> No sure why that is there. Possibly for non loop usages.

Has to be. Alex was all over this back in c.p.t