Re: [boost] shared_ptr in multithreaded environments

From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2008-03-10 22:47:20

On Mar 10, 2008, at 6:27 PM, Emil Dotchevski wrote:
> On Mon, Mar 10, 2008 at 3:18 PM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]> wrote:
>> I see that shared_ptr is quite costly in multithreaded environments
>> cause it would need DCAS, and thus uses a spinlock in cases where  
>> it is
>> not available.
>
> If you pass shared_ptr objects by const &, the refcount doesn't need
> to be updated.   ... [snip]
> -- 
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode

Yes, but be careful that the lifetime of the shared_ptr object passed  
as const & must be guaranteed to outlive the const &, otherwise you  
have a dangling reference.  That's guaranteed if the caller owns a  
copy of the shared_ptr, but not if it passes a reference to, e.g., a  
shared_ptr owned by an external data structure (e.g. a queue of  
shared_ptr objects), that can be modified by several threads or even  
by the current thread.

I've been bitten by that (shared_ptr of callbacks, you dequeue the  
callback while another thread is still processing it, and it just  
happens to destroy all the bound parameters in the callback...  
oops!)  In one pernicious instance, it's the callback itself that was  
flushing the queue and destroyed the shared_ptr that it had a const&  
to...
--
Hervé Brönnimann
hervebronnimann_at_[hidden]