Re: [Boost-users] shared_ptr race condition

On Sat, Aug 16, 2008 at 9:32 PM, David Abrahams wrote:

on Sat Aug 16 2008, "Eduardo Panisset" http://eduardo.panisset-at-gmail.com/> wrote:

...

There are two threads, each one with its own shared_ptr. Thread 2 created its shared_ptr2 by copying the shared_prt1 of thread 1. Then the reference count is equal to 2. Some time later, shared_ptr1 goes out of scope and then shared_prt2 also goes out of scope. Consider the following event sequence:

1. Thread 1 executes release member function, and it is preempted before executing comparation if (new_use_count == 0) 2. Thread 2 executes release member function until the end, disposing the pointee. 3. Thread 1 is rescheduled, executes comparation if (new_use_count == 0) and also diposes the pointee!

Is it possible, isn't it?

No. Thread 1 will see new_use_count == 1, thread 2 will see new_use_count == 0 and dispose the pointee, and thread 1 will continue off the end of the function without disposing it.

Ok, David !!! new_use_count is a local variable that receives the ref count inside the critical region synchronizing the shared variable use_count_, so there is no race condition. There is still a doubt left. How can I copy a shared_ptr from a different thread that has created it and guarantee that the pointee did not go away (race condition between function members release and add_ref_lock ) ? Please take a look: 1. Thread 2 starts copying shared_ptr already held by Thread 1 2. Before Thread 2 enters into critical region of member function add_ref_lock, it is preempted 3. Thread 1 releases its shared_ptr, disposing the pointee 4. Thread 2 is rescheduled and increments the ref count, however its pointee was disposed by Thread 1 (Item 3) One example that could generate the situation above: I could have one thread calling a clear method of std::vector, while another thread was copying a shared_ptr placed in the same std::vector. Thanks!