Re: Usefulness of weak_ptr

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

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

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 
critical sections).
 
> 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.

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, 
although it
> 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.

Bill Kempf