Re: [boost] Is shared_ptr really thread safe ?

From: Richard Jones (R.E.Jones_at_[hidden])
Date: 2002-05-07 05:14:08

Larry

I haven't been following this thread but here's my pennyworth.

The only time that action at the target is needed is when a reference is 
deleted (reduce the RC at the target). When a reference is copied, usually it 
is only necessary to divide the WRC (at the source). However, you also need to 
WRC underflow, e.g. by creating an indirection (at the source) or by increasing 
the RC at the target. The other good thing about WRC is that order of 
operations is no longer an issue (certainly good for distributed systems and  
concurrency, may also be good forcompiler optimisation, etc).
Thus, only target RC reduction (or increases to accommodate WRC overflow) need 
be atomic.

Richard

>Larry Evans wrote:
>[snip]
>
>>
>> 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.
>
>The last sentence overstated the case.  Whenever an "arc" is
>deleted is when a lock is needed.  In other words, if
>smart_weighted_ptr::get is non-null,
>then when it changes to another referent, the previous referent's
>weighted reference count must be updated; hence, a lock is required.
>However, the new referent's reference count is NOT updated, only
>the smart_weighted_ptrs' (the source and target) weighted reference
>counts are updated.  Hence, less than 1/2 of the locks are required.  The
>number of locks correspond to the number of reference count decrements
>in the current smart_ptr.
>
>At least I think that's right.  Maybe Jones or Lins could correct me.
>
>