Subject: Re: [boost] [spinlock] Spin on volatile read, NUMA fairness?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-12-04 08:40:52
On Wednesday 03 December 2014 23:41:47 Niall Douglas wrote:
> On 3 Dec 2014 at 23:29, Andrey Semashev wrote:
> > Acquire memory
> > ordering is not required for spinning, and on architectures that
> > support it it can be much more expensive than relaxed. Second, even
> > a relaxed atomic read is formally not equivalent to a volatile read.
> > The latter is not guaranteed to be atomic. Lastly, on x86 all this is
> > mostly moot because compilers typically generate small volatile
> > reads as a single instruction, which is equivalent to an acquire or
> > relaxed atomic read on this architecture, as long as alignment is
> > correct.
> I'll be honest: benchmarking whether I can drop that precheck to
> relaxed is on my todo list. As Intel can't do relaxed loads, I had
> been waiting for my ARM board, which actually arrived some months
> I'm also pretty conservative when it comes to memory ordering, and I
> would default to stronger atomic semantics rather than weaker until I
> see a compelling reason why not.
There's no point in issuing an acquire barrier on every read while spinning.
You don't accomplish anything with it. What matters is the acquire barrier
when you actually lock the mutex, which happens unconditionally after