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: arm ldxr/stxr vs cas
Date: Sun, 8 Sep 2024 13:30:50 -0700
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <vbl1hq$22022$3@dont-email.me>
References: <vb4sit$2u7e2$1@dont-email.me> <vbc4u3$aj5s$1@dont-email.me>
 <898cf44224e9790b74a0269eddff095a@www.novabbs.org>
 <vbd4k1$fpn6$1@dont-email.me> <vbd91c$g5j0$1@dont-email.me>
 <vbflk4$uc98$1@dont-email.me>
 <352e80684e75a2c0a298b84e4bf840c4@www.novabbs.org>
 <vbhpv0$1de2c$1@dont-email.me> <vbimfd$1jbai$1@dont-email.me>
 <vbimo3$1jbai$2@dont-email.me> <vbimsj$1jb9v$1@dont-email.me>
 <7ca6928a45e4cae89ba50a4623809d1c@www.novabbs.org>
 <vbjgre$1rat4$3@dont-email.me> <50kDO.14812$ORHe.9948@fx07.iad>
 <20240908204621.000062d1@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 08 Sep 2024 22:30:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d44d7012c3ec9d16fb2fdce73058c980";
	logging-data="2162754"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18MqKcL7VYac2BYPwrKt134JnNNjgLYltk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MWGGujhmhYJhpiA7KX86z6JBzsA=
Content-Language: en-US
In-Reply-To: <20240908204621.000062d1@yahoo.com>
Bytes: 3146

On 9/8/2024 10:46 AM, Michael S wrote:
> On Sun, 08 Sep 2024 16:10:41 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
> 
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 9/7/2024 5:59 PM, MitchAlsup1 wrote:
>>>> On Sat, 7 Sep 2024 23:16:35 +0000, Chris M. Thomasson wrote:
>>
>>>> Thus, it seems reasonable to fail a CAS when one cannot determine
>>>> if the memory location has been changed and changed back in the
>>>> mean time.
>>>
>>> I think Scott Lurndal mentioned something about CAS or something on
>>> windows that will assert the bus lock after a lot of failures...
>>
>> On AMD processors (and likely intel), if a core cannot acquire
>> a cache line in a a finite time, the core will assert the bus lock
>> to ensure forward progress.
>>
>> Nothing to do with the operating software;  purely a hardware thing.
> 
> 
> I think, on AMD processors made in this century the only cases that
> resort to physical bus lock are
> A) atomic accesses that cross cache boundary
> B) atomic accesses that address non-cached memory regions
> 
> Both are in realm of "Dear software, please, never do it. If you think
> that you need it, you are wrong."

Actually, an older algorithm called QPI (iirc) took advantage of this to 
get remote memory barriers by forcing the hardware to assert a bus lock 
from time to time. It was highly asymmetric in nature. A paper by Dave 
Dice comes to mind...



> And in both cases it's not related to any sort timeout.
> 
> In case of Intel, I think that since Nehalem they don't have physical
> Bus Lock signal in their processors.
>