From: Saul Tamari (saul_at_[hidden])
Date: 2002-02-12 11:29:23
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "bill_kempf" <williamkempf_at_[hidden]>
> > 1) Spin locks, by themselves, are prone to memory visibility issues.
> > 2) Spin locks use "busy waits" and thus chew up CPU resources while
> > trying to acquire the lock. Unless the lock contention is low this
> > overhead can quickly become detrimental to the performance of the
> > application.
> Actually (1) is rarely an issue, since the atomic instructions used to
> implement a spinlock usually act as memory barriers.
What instructions? The actual assembly for test-and-set is also a memory
barrier? Or an equivalent function that also calls a memory barrier?
> (2) is only part of the story. The main problem with spinlocks is that, on
> single processor system, (or when the threads that compete for a spinlock
> are executing on the same CPU), a busy-wait spinlock is useless. It spins
> until the timeslice elapses and can never grab the lock, because the other
> thread cannot release it - it isn't running.
> Another, less important, problem is that when the threads use a tight
> acquire-operate-release loop, a spinlock is not fair - thread A always
> the lock.
> Both can be fixed with inserting a ::Sleep(0), or sched_yield, although it
> can be argued that the second problem is user's fault.
Why not spin N times and if not successful do a yield? I've seen this used
in some libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk