Re: Usefulness of weak_ptr

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 
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.

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 
thread safety.

Bill Kempf