Sujet : Re: arm ldxr/stxr vs cas
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.archDate : 09. Sep 2024, 15:29:25
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbn0o6$2ed30$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
On 9/9/24 03:14, Terje Mathisen wrote:
jseigh wrote:
>
I'm not so sure about making the memory lock granularity same as
cache line size but that's an implementation decision I guess.
Just make sure you never have multiple locks residing inside the same cache line!
This the the terminology ARM uses when describing their LL/SC
implementation. It is not the best choice in terminology.
>
I do like the idea of detecting potential contention at the
start of LL/SC so you can do back off. Right now the only way I
can detect contention is after the fact when the CAS fails and
I probably have the cache line exclusive at that point. It's
pretty problematic.
I do prefer LOCK XADD instead of CAS (CmpXchg*), because the return value will also tell you which queue entry to pick/work on.
It will not be optimal when really contended, but at least one participant will make forward progress, and typically several of them.
I'm not aware of any lock-free queue algorithms that use
atomic_fetch_add that are actually lock-free, error free,
and/or don't have an ABA problem. I'm not saying there
aren't, just that I'm not aware of them.
Joe Seigh