[boost] Re: live_ptr (Was: Libraries requested or under construction)

From: Chelly (postmast.root.admi.gov_at_[hidden])
Date: 1999-07-27 21:42:10

At 10:51 PM +0100 1999.07.27, Alan Griffiths wrote:
>In message <v04020a00b3c2c5483805@[206.224.81.146]>, Chelly <postmast.ro
>ot.admi.gov_at_[hidden]> writes
>>At 08:43 PM +0100 1999.07.26, Alan Griffiths wrote:
>>>I too have something similar - see:
>>>
>>>    http://www.octopull.demon.co.uk/arglib/uncounted_ptr.html
[snip]
>>    struct Foo : live_base {
>>        // ...
>>    };
>
>Of course there is the trade off that "live_base" is incorporated into
>Foo - an intrusive mechanism which limits applicability. (The
>alternative of incorporating Foo into a template that aggregates it with
>the live_base is less flexible than using pointer types.)

Right.

>[snip]
>>
>>live_ptr isn't about ownership, but about monitoring.
>
>Both our solutions (live_ptr and uncounted_ptr) are about this, the
>difference is in implementation pattern.  You gain flexibility in
>ownership mechanism by constraining Foo to incorporate "live_base". I
>impose an ownership mechanism but remove the constraints on Foo.

Yeah. I noticed that yours was subtly different - it's interesting. It
requires that shared pointers are already being used, and allows a "weak"
reference to the shared object. In effect, the weak reference is a live_ptr
to the shared implementation data for the reference-counted pointers (i.e.
the use-count). When the data for the shared pointers is deleted (which
happens when the shared object itself is deleted), the weak references
become null.

>You are clearly able to address a different set of problems, which means
>that we are in "gut feel" territory in assessing the more general
>approach.

I keep killing good ideas by trying to push their generality too far :-)

>>However, it can be
>>used in similar ways - there could be multiple monitoring parties that all
>>"own" the object, and when any of them delete the object, all the others
>>know.
>
>This idea feels like a risky design - unless there is some inter-owner
>protocol in place then a live_ptr could become dead(?) under code that
>has checked it for use. I much prefer the simplicity of "single owner"
>model.

Certainly simple is better, but this could push the shared pointers on more
of the system. Also, this type of intrusive pointer can monitor objects on
the stack too, which is an interesting property. This seems to fit the
"weak reference" idea you talk about on the page.

Like someone mentioned, assuming that shared pointers are completely safe
is unsafe. I use the appropriate shared pointer for the design. I generally
don't make designs that have totally unconstrained use i.e. I can consider
all the situations something will be used.

For example, I have the concept of a "thread function" (very light-weight
compared to even same-process threads) implemented by a couple of classes
(the thread class and a container class for these that can run them
periodically). When running one, the thread may delete itself. To be sure I
don't access the thread after it was deleted, I use a monitoring pointer to
the thread. In this case, I can derive the thread class from the intrusive
base class. It's an elegant design to what could be a messy problem (at
least I think). (I also have the thread's destructor update the container's
next_thread_to_run iterator if it would be invalidated, thus taking all
restrictions off thread creation and deletion, even while inside an
executing thread function).

>>A variant of the live_ptr could be created that deletes the monitored
>>object when it goes out of scope, if it hasn't already been deleted.
>
>But don't return this variant from a function. :)

heh.