From: Bronek Kozicki (brok_at_[hidden])
Date: 2003-12-30 03:23:02
Peter Dimov <pdimov_at_[hidden]> wrote:
> Bronek Kozicki wrote:
>> I want to initialize auto_ptr from it. Thus (assuming release is
>> it may contain:
>> if (!unique())
>> throw some_exception();
>> ... and it's OK for me.
> 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.
OK, so lets leave release without this test, and document that
shared_ptr must be unique, otherwise undefined behaviour occurs. There
are 4 use cases:
* simplest case : single threaded program, pointer is guaranteeed to be
unique by program logic. User will use this feature as is, without any
special coding (this is my case currently)
* single threaded program, pointer is NOT guaranteed to be unique. User
must write own test "if (ptr.unique()) aptr = ptr.release(); // ..."
* multiple threaded program, pointer is guaranteed to be unique - it's a
question for you, actually. Can actual release be safe in such
conditions, without locking ? (my project may evolve to this case)
* multiple threaded program, pointer is NOT guaranteed to be unique.
User must write own test, and guard it (together with release) in
critical section or using other lock (eg. mutex). If release occurs in
more than one place in program, the same lock must be used in all
> No, you don't need to manage the lifetime of the deleter; it is
> managed by shared_ptr. You only need "get_deleter<D>(px)->released_ =
> true;", but this won't of course affect the pointer value of the
> shared_ptr copies, if they exist.
Thanks. In my case pointer is unique, but anyway such solution seems
worse than simple release.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk