Boost logo

Boost :

Subject: Re: [boost] [shifted_ptr] Documentation
From: Phil Bouchard (philippe_at_[hidden])
Date: 2011-04-09 15:42:04


On 4/9/2011 3:48 AM, Peter Dimov wrote:
> Phil Bouchard wrote:
>> And an overview is available here:
>> http://www.fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/overview.html
>>
>>
>> Please let me know if anything isn't clear enough.
>
> It's not clear how shifted_ptr detects cyclic blocks of memory with no
> coding overhead. The methods with which I'm familiar require (a) the
> ability to enumerate all pointer subobjects in an object and (b) the
> ability to zero these pointers so as to break the cycles. Without some
> sort of registry that tracks all pointer instances (overhead on
> construction/destruction) (a) requires cooperation from the pointee,
> which shifted_ptr does not seem to demand.

It stacks up all allocations made on the heap to later track within
which memory block a shifted_ptr belong to. This is what pool::top()
defined in "sh_owned_base_nt.hpp" does. Once a pointer from the stack
is reached then the set counter is shared will all of the newly
allocated blocks of memory.

> It's also not clear how cyclic structures are detected immediately.
> Doing this typically either requires a scan (collection cycle) on every
> pointer destruction, or some sort of housekeeping on each construction
> and copy.

I haven't added diagrams yet but the text of the rationale can be found
here:
http://www.fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/rationale.html

> It is also not clear how well does the cyclic collector work when, in
> parallel, other threads create and destroy references to the objects
> being currently scanned.

The pools are designed to be used by a multithreaded environment and so
is the reference counter base class but the manipulation of set haven't
been tested yet. Perhaps a mutex can be added to the set counter if an
atomic mechanism isn't found.

Thanks,
-Phil


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk