Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: arm ldxr/stxr vs cas
Date: Thu, 5 Sep 2024 19:46:25 +0000
Organization: Rocksolid Light
Message-ID: <898cf44224e9790b74a0269eddff095a@www.novabbs.org>
References: <vb4sit$2u7e2$1@dont-email.me> <07d60bd0a63b903820013ae60792fb7a@www.novabbs.org> <vbc4u3$aj5s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="981121"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$gbc55Z8enpu7Gxlqfy/9/.8fLwAYU7kPZ3So5JtTMEHqUg54NaoPG
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3460
Lines: 50

On Thu, 5 Sep 2024 11:33:23 +0000, jseigh wrote:

> On 9/4/2024 5:27 PM, MitchAlsup1 wrote:
>> On Mon, 2 Sep 2024 17:27:57 +0000, jseigh wrote:
>>
>>> I read that arm added the cas instruction because they didn't think
>>> ldxr/stxr would scale well.  It wasn't clear to me as to why that
>>> would be the case.  I would think the memory lock mechanism would
>>> have really low overhead vs cas having to do an interlocked load
>>> and store.  Unless maybe the memory lock size might be large
>>> enough to cause false sharing issues.  Any ideas?
>>
>> A pipeline lock between the LD part of a CAS and the ST part of a
>> CAS is essentially FREE. But the same is true for LL followed by
>> a later SC.
>>
>> Older machines with looser than sequential consistency memory models
>> and running OoO have a myriad of problems with LL - SC. This is
>> why My 66000 architecture switches from causal consistency to
>> sequential consistency when it encounters <effectively> LL and
>> switches bac after seeing SC.
>>
>> No Fences necessary with causal consistency.
>>
>
> I'm not sure I entirely follow.  I was thinking of the effects on
> cache.  In theory the SC could fail without having get the current
> cache line exclusive or at all.  CAS has to get it exclusive before
> it can definitively fail.

A LL that takes a miss in L1 will perform a fetch with intent to modify,
so will a CAS. However, LL is allowed to silently fail if exclusive is
not returned from its fetch, deferring atomic failure to SC, while CAS
will fail when exclusive fails to return. LL-SC is designed so that
when a failure happens, failure is visible at SC not necessarily at LL.

There are coherence protocols that allows the 2nd party to determine
if it returns exclusive or not. The example I know is when the 2nd
party is already performing an atomic event and it is better to fail
the starting atomic event than to fail an ongoing atomic event.
In My 66000 the determination is made under the notion of priority::
the higher priority thread is allows to continue while the lower
priority thread takes the failure. The higher priority thread can
be the requestor (1st party) or the holder of data (2nd party)
while all interested observers (3rd parties) are in a position
to see what transpired and act accordingly (causal).

> Whenever they get around to making arm desktops without the OS tax
> so I can install linux I can compare the 2.
>
> Joe Seigh