Path: ...!eternal-september.org!feeder2.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: Arm ldaxr / stxr loop question
Date: Sat, 9 Nov 2024 13:47:43 -0800
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vgol9u$3vr0c$2@dont-email.me>
References: <vfono1$14l9r$1@dont-email.me>
 <YROdnVIXfKmwYrn6nZ2dnZfqn_GdnZ2d@supernews.com>
 <vg5tf7$3tqmi$2@dont-email.me> <vgm0g1$3c2t2$3@dont-email.me>
 <zwwXO.842112$_o_3.379966@fx17.iad> <vgm4vj$3d2as$1@dont-email.me>
 <vgmanf$3dv51$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 09 Nov 2024 22:47:43 +0100 (CET)
Injection-Info: dont-email.me; posting-host="42a0198f79e20e1c99d0f1a5c57bc090";
	logging-data="4189196"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oaU52krIItU8h4kDWV/u/nFQbHnG6CbE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:f0qCHU4nqsTep0XoCBvSDRc0pZw=
In-Reply-To: <vgmanf$3dv51$1@dont-email.me>
Content-Language: en-US
Bytes: 3668

On 11/8/2024 4:34 PM, jseigh wrote:
> On 11/8/24 17:56, Chris M. Thomasson wrote:
>> On 11/8/2024 2:45 PM, Scott Lurndal wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/2/2024 12:10 PM, Chris M. Thomasson wrote:
>>>>> On 11/1/2024 9:17 AM, aph@littlepinkcloud.invalid wrote:
>>>>>> jseigh <jseigh_es00@xemaps.com> wrote:
>>>>>>> So if were to implement a spinlock using the above instructions
>>>>>>> something along the lines of
>>>
>>>>
>>>> Fwiw, I am basically asking if the "store" stxr has implied acquire
>>>> semantics wrt the "load" ldaxr? I am guess that it does... This would
>>>> imply that the acquire membar (#LoadStore | #LoadLoad) would be
>>>> respected by the store at stxr wrt its "attached?" load wrt ldaxr?
>>>>
>>>> Is this basically right? Or, what am I missing here? Thanks.
>>>>
>>>> The membar logic wrt acquire needs to occur _after_ the atomic logic
>>>> that locks the spinlock. A release barrier (#LoadStore | #StoreStore)
>>>> needs to occur _before_ the atomic logic that unlocks said spinlock.
>>>>
>>>> Am I missing anything wrt ARM? ;^o
>>>
>>> Did you read the extensive description of memory semantics
>>> in the ARMv8 ARM?   See page 275 in DDI0487K_a.
>>>
>>> https://developer.arm.com/documentation/ddi0487/ka/?lang=en
>>
>> I did not! So I am flying a mostly blind here. I don't really have any 
>> experience with how ARM handles these types of things. Just guessing 
>> that the store would honor the acquire of the load? Or, does the store 
>> need a membar and the load does not need acquire at all? I know that 
>> the membar should be after the final store that actually locks the 
>> spinlock wrt Joe's example.
>>
>> I just need to RTFM!!!!
>>
>> Sorry about that Scott. ;^o
>>
>> Perhaps sometime tonight. Is seems like optimistic LL/SC instead of 
>> pessimistic CAS RMW type of logic?
> 
> 
> In this case the the stxr doesn't need a memory barrier.

So, once that stxr completes it already has acquire membar semantics 
from its prior load wrt its acquire? Never mind. I am busy right now on 
some other things.


> Loads can move forward of it but not forward of the ldaxr
> because it has acquire semantics.  For a lock that's ok
> since the stxr would fail if any other thread acquired
> the lock the conditional branch would make the loads
> speculative if the stxr failed I believe.
> 
> Joe Seigh