Re: [boost] boost::shared_ptr<> uses mutex rather than CAS methods

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-12-09 12:52:47

On Thu, 09 Dec 2004 09:32:05 -0800, Dayton <mvglen04-cnews_at_[hidden]> wrote:
> Shared_ptr<> down deep uses a light-weight mutex to protect the
> increment and decrement of its reference count.  A mutex isn't needed
> here.  A mutex may yield the context of execution.  This seems silly to
> protect a single instruction.
> 
> To support threads, all modern processors offer some form of interlocked
>   operation or atomic compare-and-swap instruction.  On SPARC cpus, it
> is the CAS instruction, which acts much like a spin-lock.  Windows
> offers InterlockedIncrement() and InterlocledDecrement() functions,
> which in the newer Microsoft compilers may be compiled as an intrinsic.
> 
> I'm a bit allergic to context yielding synchronization objects thrown
> randomly into my server code.  Does anyone know of any reasons to not
> use CAS-style programming here before I propose using it for smart_ptr<>?
> 
> Glen

This should probably be a FAQ.  I'm sure there are lots of messages in
archive about this.

Peter Dimov, or one of the Peters, I think has such an interlocked
implementation which you'll find referred to in the message archive. 
Though the issue, from memory, is that there are two counts, for the
weak and "strong" references and a lightweight mutex is about the same
cost as two interlocked or CAS style ops so there is not necessarily a
big benefit in changing.  Explicit, yielding is a bad thing though...

However, this leave the shared_ptr as a slowish pointer in a
multithreaded environment if that is important to you.  Even in a
multithreaded code base you often want a fast single threaded smart
pointer for appropriate situations, the current shared_ptr is not
appropriate here either.  A policy based design should allow you to
customise these decisions as Loki's smart pointer shows.  I think
David Held is the closest to a reification of this abstraction for
boost.  There are many issues with policy based designs, especially
without template typedefs in the language and w.r.t. compatibility,
that have been discussed in the past, which is why the current
shared_ptr interface design is perhaps the best common denominator to
be useful to the widest audience.  We are better with it than with
arguing endlessly about the best approach...

Another thought is to be aware that the count can be wrong sometimes
and the semantics can still work.  Researchers have used this to make
faster reference counting work.  That is, it doesn't matter if your
count is wrong and too high, all that really matters is that someone
gets a zero when the references are eliminated.  I can probably dig
out a reference to the paper I'm thinking of, if anyone is
interested...

You also raise an interesting point that as well as having correctness
unit tests, boost should probably have performance benchmarking unit
tests for libs where appropriate as performance needs to be checked
and monitored for many lib components.

HTH,

matt
matthurd_at_[hidden]