|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-12 07:50:10
From: "bill_kempf" <williamkempf_at_[hidden]>
> --- 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 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.
(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 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 gets
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk