Deutsch   English   Français   Italiano  
<vh0s1v$1rohh$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: 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: Tue, 12 Nov 2024 16:32:00 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vh0s1v$1rohh$1@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>
 <vgm5cb$3d2as$3@dont-email.me> <OnzXO.657386$1m96.281665@fx15.iad>
 <TfKXO.658488$1m96.146506@fx15.iad> <T99YO.79275$MoU3.7336@fx36.iad>
 <3lGdnVvGQIAq2676nZ2dnZfqnPGdnZ2d@supernews.com>
 <vh0jo6$1q1hl$3@dont-email.me>
 <0TmdnaP6ecXoQ676nZ2dnZfqn_adnZ2d@supernews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 13 Nov 2024 01:32:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="6a1ff3e9645d38e0c84409251fc3c409";
	logging-data="1958449"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+KiQEn+gAwO9gKiJNN3yOWBUdn6U4MPJc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qjqFFetmP6MGx6/ynNo0aoHtUfg=
Content-Language: en-US
In-Reply-To: <0TmdnaP6ecXoQ676nZ2dnZfqn_adnZ2d@supernews.com>

On 11/12/2024 3:02 PM, aph@littlepinkcloud.invalid wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 11/12/2024 4:14 AM, aph@littlepinkcloud.invalid wrote:
>>>
>>> One other thing to be aware of is that the StoreLoad barrier needed
>>> for sequential consistency is logically part of an LDAR, not part of a
>>> STLR. This is an optimization, because the purpose of a StoreLoad in
>>> that situation is to prevent you from seeing your own stores to a
>>> location before everyone else sees them.
>>
>> Fwiw, even x86/x64 needs StoreLoad when an algorithm depends on a
>> store followed by a load to another location to hold. LoadStore is
>> not strong enough. The SMR algorithm needs that. Iirc, Peterson's
>> algorithms needs it as well.
> 
> That's right, but my point about LDAR on AArch64 is that you can get
> sequential consistency without needing a StoreLoad.

Ahhh. So, well, it makes me think of the implied StoreLoad in x86/x64 
LOCK'ed RMW's...? Does this make any sense to you? Or, am I wandering 
around in a damn field somewhere! ;^o

I am so used to SPARC style in RMO mode. The LoadStore should be _after_ 
any "naked", but atomic logic that acquires and releases a spinlock... 
;^o acquire with regard to the memory barrier logic, -not- the atomic 
logic that gains the lock itself....


>  LDAR can peek
> inside the store buffer and, much of the time, determine that it isn't
> necessary to do a flush. I don't know if Arm were the first to do
> this, but I don't recall seeing it before. It is a brilliant idea.