From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-12 14:04:43
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > If that's true, why do people bother with critical sections and
> > pthread
> > > mutexes instead of simply using spinlocks? :-)
> > It is true. There are a couple of reasons to not use a spin lock,
> > though.
> > 1) Spin locks, by themselves, are prone to memory visibility
> > 2) Spin locks use "busy waits" and thus chew up CPU resources
> > trying to acquire the lock. Unless the lock contention is low
> > overhead can quickly become detrimental to the performance of the
> > application.
> Actually (1) is rarely an issue, since the atomic instructions used
> implement a spinlock usually act as memory barriers.
This is not necessarily the case. The atomic instructions may only
gaurantee the memory visibility of the integral type being acted on.
A full memory barrier need not be used.
> (2) is only part of the story. The main problem with spinlocks is
that, on a
> single processor system, (or when the threads that compete for a
> are executing on the same CPU), a busy-wait spinlock is useless. It
> until the timeslice elapses and can never grab the lock, because
> thread cannot release it - it isn't running.
Yes, but a spin lock need not behave this way. It can relinquish the
timeslice on the first failure in single processor systems. Of
course, the act of performing the context switch at this point can be
expensive, but generally not as expensive as most kernel level
synchronization. I've made use of such spin locks on single
processor systems and saw a definate performance boost over Win32
mutexes (though on some Win32 platforms I saw worse performance then
> Another, less important, problem is that when the threads use a
> acquire-operate-release loop, a spinlock is not fair - thread A
> the lock.
That, again, depends on the implementation, though it is true that
spin locks are never fair.
> Both can be fixed with inserting a ::Sleep(0), or sched_yield,
> can be argued that the second problem is user's fault.
The fact is, though, that in this particular case a spin lock might
well prove to be effective... just not very portable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk