From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-06-16 07:16:57
On 06/16/2005 06:38 AM, Peter Dimov wrote:
> Larry Evans wrote:
>>to find the roots, at least AFAICT. Is this intentional, ...
> Yes, this is intentional, as reset_and_collect does not require any help
> from the implementation of shared_ptr, so it can be used with
> tr1::shared_ptr as well. It has been developed in response to Eric Niebler's
> scenario where the roots that form cycles are known to the programmer.
Ah! My mind's fog is lifting slightly ;)
> It's possible to combine the two approaches and perhaps provide a default
> enable_tracking that does a memory scan as in sp_collector. I think that in
I would be nice if somehow the method for finding a referent's contained
smart_ptr's could be a determined by a policy.
> most typical cyclic shared_ptr situations the problematic roots are known in
> advance, though, so a reset_and_collect-type solution may be enough.
Hadn't thought of that.
> Note that reset_and_collect is perfectly capable of figuring out on its own
> that unknown roots to a node exist, it only needs a starting point (and can
> be modified to work with several starting points).
Hmm... is this anything like the 'local mark scan' in [mart90] cited on
Jones page? Give a node, call it the subroot node, it traverses nodes
reachable from that while decrementing the refcounts. If the subroot
node still has a positve refcount, it can't be in a cycle; so, it
undoes the decrementing. I'm guessing that the difference is that:
1) reset_and_collect doesn't decrement, it only increments the value
associated with the node's key in a map_type.
2) instead of user selection of the staring point, the selection is
made each time a decrement is made, and the starting point is
the smart_ptr making the decrement.
The modification to several starting points sounds like it may be a
variation of the method in [lins90a], where a decrement doesn't
immediately scan the subnodes, but waits until a que of decremented
smart_ptr's is filled, and then scan's nodes reachable from each
element in the que. Is that, at least approximately, what's happening
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk