[boost] Re: how do I release shared_ptr ?

From: Joe Gottman (jgottman_at_[hidden])
Date: 2004-01-08 20:14:46

"Joe Gottman" <jgottman_at_[hidden]> wrote in message
news:btil6v$f60$1_at_sea.gmane.org...
>
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:ur7yb6t0m.fsf_at_boost-consulting.com...
> > "Joe Gottman" <jgottman_at_[hidden]> writes:
> >
> > > "David Abrahams" <dave_at_[hidden]> wrote in message
> > > news:u8ykjepph.fsf_at_boost-consulting.com...
> > >> "Peter Dimov" <pdimov_at_[hidden]> writes:
> > >>
> > >> > Jason House wrote:
> > >> >> Peter Dimov wrote:
> > >> >>
> > >> >>> When multiple threads are involved there is a race condition
> between
> > >> >>> the unique() test and the actual release, and I'm not sure how
such
> > >> >>> a feature would interact with a lock-free implementation.
> > >> >>
> > >> >>
> > >> >> I think this statement might be incorrect.  If nothing else, I
think
> > >> >> some careful thought about it might yield an easy solution to the
> > >> >> problem. If I understand right, a shared_ptr will be unique if and
> only
> > > if
> > >> > it
> > >> >> is the only shared_ptr to that object.  In that scenario, there
will
> be
> > >> >> no other shared_ptr's in any other threads that could cause the
> > >> >> reference count to change from 1 at any instant in time...
> > >> >
> > >> > You're almost right, except for one small detail; weak pointers do
> not
> > >> > affect unique(), and can generate other shared_ptr copies.
> > >>
> > >> Maybe we want weak_unique(), or we want to change unique() so that it
> > >> returns weak_count.
> > >>
> > >> We should look again at the use cases for unique().  Maybe they're
> > >> supported just as well or better by weak_count.
> > >>
> > >
> > >     One major use for unique() is copy-on-write.  The code would look
> > > something like:
> > >
> > >     void write_to(shared_ptr<Foo> p, const Foo &newValue)
> > >     { // For simplicity, assume p.get() != 0
> > >         if (p.unique()) {
> > >             *p = newValue;
> > >         } else {
> > >             p.reset(new Foo(newValue));
> > >         }
> > >     }
> > >
> > > Under the current definition of unique(), this code is impossible to
> make
> > > thread-safe if weak_ptrs might exist.
> >
> > Would it work just as well if unique() returned weak_count?
> >
>
>    It would work better. If nobody is using weak_ptrs then weak_count
equals
> 1 if and only if shared_count equals 1.  And if weak_ptrs are possible,
then
> having unique() depend on weak_count guarantees that this code is
> thread-safe.

   I just realized that weak_ptr's and copy-on-write don't work together at
all, no matter how you define unique().  Consider the following code:

   shared_ptr<int> p(new int(1));
   weak_ptr<int>  w(p);
   write_to(p, 2);
    shared_ptr<int> p2 = w.lock();

    You would want *p2 to be equal to 1 in this case, but it won't.  If
unique()  is based on the shared_count, then write_to will have set *p = 2,
so now *p2 == 2 also.  On the other hand, if unique() is based on the
weak_count, then write_to will have called reset() on p.  This removed the
last shared_ptr associated to w, so now p2 = w.lock() will be empty.

Joe Gottman