Sujet : Re: arm ldxr/stxr vs cas
De : chris.m.thomasson.1 (at) *nospam* gmail.com (Chris M. Thomasson)
Groupes : comp.archDate : 08. Sep 2024, 21:30:50
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbl1hq$22022$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla Thunderbird
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.