Re: [boost] Re: Usefulness of weak_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-12 14:20:41

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

Depends on how the atomic operation is documented to perform. The CPU
instruction itself may or may not synchronize memory, but the atomic
primitive is _usually_ documented to act as a memory barrier. It would be
very difficult to use otherwise (see the comments in atomic_count.hpp.)

In particular, ::InterlockedXXX (Win32) and atomic_* (linux) are documented
to be memory barriers... if you can call that documentation but that's
another story.

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

Well, it's either a busy-wait loop or it's not, right? By "spinlock" above I
meant the busy-wait variant that you described in (2).

Apart from that I agree with your comments.