Re: [Boost-users] Thread Safety of shared_ptr

Subject: Re: [Boost-users] Thread Safety of shared_ptr
From: ÇÇ־ǿ (qiaozhiqiang_at_[hidden])
Date: 2011-05-02 21:24:42

 shared_ptr< Session >* sp_Session = new shared_ptr< Session >( new
 Session );

shared_ptr< Session >* is not a shared ptr, it is a RAW ptr to shared_ptr< Session>.

So you should:
1. use shared_ptr of shared_ptr:
shared_ptr<shared_ptr< Session > >  sp_Session ( new shared_ptr< Session >( new
 Session )) ;

2. or use shared_ptr directly:
shared_ptr< Session > sp_Session( new Session );

I think you should use 2.
 

  
> ------------------------------
> 
> Message: 7
> Date: Tue, 3 May 2011 10:46:39 +1000
> From: "Kevin Frey" <kfrey_at_[hidden]>
> To: <boost-users_at_[hidden]>
> Subject: Re: [Boost-users] Thread Safety of shared_ptr
> Message-ID:
> 	<95C19A2ED65BF54CB79DF1F9D6A488E0013E3351_at_hcmail1.MEL01.hardcat.com.a
> u>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> > Actually, I am not sure with this statement. Destructor is only called
> if shared count reaches zero. I don't think that this can happen, that a
> dtor is called in one thread and the other thread is still able to
> increment the shared count even from the weak_ptr. I remember reading
> weak_ptr's source and saw that it is also protected again such a case.
> 
> 
> 
> I have taken the example at face value, but in hindsight the examples
> could be a lot better because there is no context to describe the
> circumstances of how the shared_ptrs are instantiated.
> 
> 
> 
> For example, is p allocated globally, and p2 & p3 allocated at the
> beginning of their respective threads? If so, example 4 becomes
> meaningless because Thread B cannot force p2 out of scope since it would
> only go out of scope once thread A exits, since thread A controls the
> scope of p2. If thread B were to force p2 "out of scope" then p2 would
> have to be a shared_ptr< >*, dynamically allocated., and subsequently
> deleted by Thread B. But it is not represented that way.
> 
> 
> 
> Unfortunately none of this helps solve my original question, which given
> the direction this thread is proceeding, I will re-state in pseudo-code
> that approximates the *actual* situation occurring in my program:
> 
> 
> 
> Earlier on:
> 
> 
> 
> shared_ptr< Session >* sp_Session = new shared_ptr< Session >( new
> Session );
> 
> 
> 
> Dependent_Class* dep = new Dependent_Class( shared_ptr< Session >&
> shared_ptr_session );
> 
> In Dependent_Object::Dependent_Object( )
> 
>    this->sp_Session = new shared_ptr< Session >( shared_ptr_session );
> 
> Now, simultaneously:
> 
> 
> 
> Thread A:
> 
> Dependent_Class* dep2 = new Dependent_Class( shared_ptr< Session>&
> shared_ptr_session );
> 
> In Dependent_Object::Dependent_Object( )
> 
>    this->sp_Session = new shared_ptr< Session >( shared_ptr_session );
> 
> 
> 
> Thread B:
> 
> In Dependent_Class::~Dependent_Class( ): // the cleanup of dep
> 
>    delete this->sp_Session;
> 
> 
> 
> So, we have:
> 
> 
> 
> 1.       A shared object (pointed to by a shared_ptr) that is presently
> in existence with a reference count of at least 2.
> 
> 2.       One thread A creating another shared_ptr to the shared object,
> attempting to increment the reference count.
> 
> 3.       Another thread B simultaneously destroying a *different*
> shared_ptr which is connected to the same underlying shared object,
> decrementing the reference count.
> 
> 
> 
> Note that the shared object is *not being destroyed* here, just the
> reference counts are being manipulated.
> 
> 
> 
> Will shared_ptr handle this situation correctly?
> 
> 
> 
> Thanks
> 
> 
> 
> Kevin
> 
> 
>