Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.arch Subject: Re: Arguments for a sane ISA 6-years later Date: Mon, 29 Jul 2024 12:13:27 -0700 Organization: A noiseless patient Spider Lines: 35 Message-ID: References: <2024Jul26.190007@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 29 Jul 2024 21:13:29 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e7ff1aa5790f368a9ad3a21131725cb1"; logging-data="643409"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/k4B41cUlYUeGDMzgxFr9SU6uQmCaZtoE=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:TUzRRWntA7HyCexDqqbtOPnFecY= Content-Language: en-US In-Reply-To: Bytes: 2450 On 7/29/2024 11:55 AM, Chris M. Thomasson wrote: > On 7/29/2024 12:25 AM, BGB wrote: [...] >> Though, one does have the issue that one can't just use cheap spinlocks. > > One note... Spinlocks work in a very weak memory model for sure. You > just need the right memory barrier logic... For instance, SPARC in RMO > mode wrt locking a spinlock and/or mutex requires a #LoadStore | > #LoadLoad membar _after_ the atomic logic that actually locks it occurs. > It also requires a release membar #LoadStore | #StoreStore _before_ the > atomic logic that unlocks it takes place. Take note that #StoreLoad is > _not_ required for a spinlock or a mutex in this context... Basically: ______________________ atomic_lock(); membar #LoadStore | #LoadLoad; { // inside the locked region... } membar #LoadStore | #StoreStore; atomic_unlock(); ______________________ atomic_lock/unlock are meant to be memory barrier free. Hopefully simple and efficient, say an XCHG (xchg had implied lock prefix) on the x86. Actually, one can release a spinlock on x86 with a single store (MOV) because of the implied release semantics wrt TSO. MOV instead of a locked RMW. [...]