From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-11 16:15:30
--- In boost_at_y..., "Wyss, Felix" <felixw_at_i...> wrote:
> > It is true. There are a couple of reasons to not use a spin
> > 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.
> In addition, a simple atomic-exchange spinlock is not reentrant.
Neither are most mutexes. Win32 is a unique criter in this regard.
That's why I left that qualification off.
> > 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.
That's a valid decision, but you have to decide which "canned"
policies are provided and supported, which would leave me back at the
mutex only solution for the reasons given above. The user is still
free to define his own policy, which is a "win win" situation.
Moreover, using policies allows a null_mutex policy to be used for
either ST programs, or for cases where we know there's no need for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk