|
|
Boost : |
From: Wyss, Felix (felixw_at_[hidden])
Date: 2002-02-11 15:48:26
> 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.
In addition, a simple atomic-exchange spinlock is not reentrant.
> However, if it were me, I'd stick with the mutex/critical section
> since it's easy to maintain and is more portable.
Why not make it a policy? That's what we did. We basically use a "threading model" policy that specifies the type of the lock. We also have a "single threaded" policy that resolves to a NO-OP lock.
Felix
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk