[boost] Re: how do I release shared_ptr ?

From: Joe Gottman (jgottman_at_[hidden])
Date: 2004-01-07 20:50:19

"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.

Joe Gottman