Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.arch
Subject: Arm ldaxr / stxr loop question
Date: Mon, 28 Oct 2024 15:13:03 -0400
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <vfono1$14l9r$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 28 Oct 2024 20:13:05 +0100 (CET)
Injection-Info: dont-email.me; posting-host="45964397d560bbf91335e03cd6cda79a";
	logging-data="1201467"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19iCJlYGyzmNOSTpvz5BUB8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:91N365kr1S5FGp09g6ZDFBWFyhk=
Content-Language: en-US
Bytes: 2092

So if were to implement a spinlock using the above instructions
something along the lines of

..L0
	ldaxr    -- load lockword exclusive w/ acquire membar
	cmp      -- compare to zero
	bne  .LO -- loop if currently locked
         stxr     -- store 1
         cbnz .LO -- retry if stxr failed

The "lock" operation has memory order acquire semantics and
we see that in part in the ldaxr but the store isn't part
of that.  We could append an additional acquire memory barrier
but would that be necessary.

Loads from the locked critical region could move forward of
the stxr but there's a control dependency from cbnz branch
instruction so they would be speculative loads until the
loop exited.

You'd still potentially have loads before the store of
the lockword but in this case that's not a problem
since it's known the lockword was 0 and no stores
from prior locked code could occur.

This should be analogous to rmw atomics like CAS but
I've no idea what the internal hardware implementations
are.  Though on platforms without CAS the C11 atomics
are implemented with LD/SC logic.

Is this sort of what's going on or is the explicit
acquire memory barrier still needed?

Joe Seigh