[boost] Re: how do I release shared_ptr ?

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-07 22:03:53

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com