Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: arm ldxr/stxr vs cas
Date: Sun, 8 Sep 2024 20:46:21 +0300
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <20240908204621.000062d1@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 08 Sep 2024 19:46:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46daed28da5e223c25c4774ca01ab553";
	logging-data="2041887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FiTh6G7TRv/EFylk8vHY2WRWSDea2qsw="
Cancel-Lock: sha1:vtAi9v7CSJ4GLh+zzUSSdUSzIok=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2780

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."
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.