Peter Dimov  Wrote:

##################################################################
Is it possible for a thread to still be calling c->getList when ~C is executed?

Based on your (pseudo)code, a number of temporary std::list<shared_ptr<A>> instances are created and destroyed without a problem before C's member, so list destruction on its own seems to work fine.  
########################################################################

C is a singleton class and from the logs i can see that the other threads have exited before the destructor of C is called. Even if the thread calls c->getList after ~C is executed, then also it should not cause a problem because until all the instances are deleted and reference count of the shared pointers reaches zero the memory for the allocated class should not be deleted. 
Or is there a race condition when both the C class is decrementing the reference count of the shared pointer and the threads reference count are being decremented simultaneously ? But then again from the stack the reference count decrementing is an atomic operation, so should not be an issue right ? 

On Tue, Jan 3, 2012 at 11:54 PM, Peter Dimov <pdimov@pdimov.com> wrote:
sumanth krishna wrote:

#8  0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value optimized out>)

Is it possible for a thread to still be calling c->getList when ~C is executed?

Based on your (pseudo)code, a number of temporary std::list<shared_ptr<A>> instances are created and destroyed without a problem before C's member, so list destruction on its own seems to work fine.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users