|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-01-07 10:35:54
"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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk