Boost logo

Boost Users :

From: Eduardo Panisset (eduardo.panisset_at_[hidden])
Date: 2008-08-16 21:54:22


On Sat, Aug 16, 2008 at 9:32 PM, David Abrahams <dave_at_[hidden]> wrote:

>
> on Sat Aug 16 2008, "Eduardo Panisset" <eduardo.panisset-AT-gmail.com<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!



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net