[boost] Is shared_ptr really thread safe ?

From: Chris Elliott (cpelliott_at_[hidden])
Date: 2002-05-03 12:00:31

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. 
Therefore before we get a chance to increment the
count, it could be decremented, but it could not go
below 1.

--- Christophe Meessen wrote:
Suppose three threads attempting to do something on
the shared_ptr.
T1 is first and access the protected counter.
T2 arrives just then, and is executing reset(). So it
blocks on the
mutex and waits for T1 to complete its operation. 
The T3 arrives and copies the shared_ptr to another
one, so it should
increment.

When T1 leaves, T2 executes and decrement the counter
that reaches 0
while T3 is waiting and planned to increment it.

A stupid implementation would destroy the object once
the counter
reaches 0. Thus T2 would delete the object although T3
is waiting on the
mutex and in fact was planning to increment the
counter. 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com