Re: [boost] Re: Usefulness of weak_ptr

From: Saul Tamari (saul_at_[hidden])
Date: 2002-02-12 11:29:23

From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "bill_kempf" <williamkempf_at_[hidden]>
...
> > 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.

What instructions? The actual assembly for test-and-set is also a memory
barrier? Or an equivalent function that also calls a memory barrier?

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

Why not spin N times and if not successful do a yield? I've seen this used
in some libraries.

Saul