Re: [boost] Is shared_ptr really thread safe ?

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-05-03 21:19:39

Chris Elliott wrote:

> The potential race condition you describe cannot occur
> with the smart_ptr design.  They are thread-safe with
> a mutex or atomic operations.
>
> The race condition described is a temporary drop of
> the reference count to 0 while a smart pointer is
> waiting to increment the reference count.  Here is why
> that can't happen.
>
> The incrementing occurs when a smart pointer is
> copied, through operator= or copy constructor, etc.
> Throughout this call there must exist another smart
> pointer to the object (specifically the one we are
> copying).  In C++ there is no way the source smart
> pointer could go out of scope during the operator= or
> copy constructor for the destination smart pointer.

Couldn't the source be in another thread; hence, could
go out-of-scope?  See

  http://pages.prodigy.net/jcampbell3/is_shared_ptr_thread_safe/2002-09-11.1745.jcampbell3.txt

for code and a detailed example which is a little different
from Meessen's.  I think I had Meessen's quandry and
Kaz's replies in http://pages.prodigy.net/jcampbell3/is_shared_ptr_thread_safe
still left me puzzled, but I think I understand now.  The rule is:

    You can't access a smart_ptr across threads.  You can only access the
    pointee across threads because the pointee is guarded by the mutex.

I hope that's correct.  Now, if this is true, then I think things could
be speeded up by using "weighted reference count" or WRC's.
With WRC's, the only time a lock is needed is during deletion of
a smart_ptr.  WRC's are described in:

    Richard E. Jones and Rafael D. Lins.
    Cyclic weighted reference counting without delay.
   Technical Report 28-92, Computing Laboratory, The University of
   Kent at Canterbury, December 1992.

This extra speed is bought at the cost of storing the "weights" in
each smart pointer.  Since each smart_ptr copy only involves accessing
the source and target smart_ptrs (the pointee is not needed), there's
no need for expensive mutex synchronization.  This, of course, assumes
that the source and target smart_ptrs are in the same thread.  But that
requirement is what Kaz was saying is needed anyway.  There's another
disadvantage to WRC in that the weight may go to 0, and I'm not sure what
to do in that case; however, I think Jones or Lins would have some idea.