Re: [boost] [Root Pointer] New Documentation

Subject: Re: [boost] [Root Pointer] New Documentation
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-04-10 14:21:02

On 04/10/2016 01:01 PM, Artyom Beilis wrote:
>
> I looked over documentation...
>
> Questions:
>
> 1. From what I understand it is basically reference-counting pointer
> with a "pool" that deletes pointers with dangling references. Am I
> right?

It really is a set of allocated blocks that are linked together using an 
intrusive list.  When the last root_ptr referring to this set is 
destroyed then the whole set of allocated blocks is destroyed, 
regardless of cycles.

> 2. What I thread safety assumptions on this library? i.e. does it use
> atomic operations to handle reference counters?

- It uses the same atomic operations as shared_ptr to handle the 
reference counter.
- It also uses a global mutex when an assignment is made.  This global 
mutex could be optimized but apparently there is no urgent need to do so 
because the speed of root_ptr is already faster than shared_ptr in 
multithreaded mode:
http://philippeb8.github.io/root_ptr//images/performance.png

> 3. What happens when root_ptr is deleted and node_ptr exists? Does use
> of node_ptr lead to undefined behavior? If so it should be marked as
> big warning.

You can't construct a node_ptr without a root_ptr so node_ptrs are 
always instantiated after a root_ptr.

> I want to add a small thing.
>
>  From my point of view the biggest issue of shared_ptr/reference
> counting isn't cyclic references (that are easily broken with weak
> references and some smart programming) but rather the overhead of the
> atomic operations that cost hundreds of cycles and cache invalidation.
> This is BTW one of the major reasons GC is more efficient in certain
> scenarios.

GC aren't deterministic so if you use Java or Javascript for a end-user 
interface, there's always going to be that annoying lag which looks 
unprofessional.

> Run benchmarks of copying pointers as well in single core case and
> multiple core cases.
>
> IMHO it is interesting concept a sort of merge between object/memory
> pool and shared_ptr.
>
> I think that due to the simple fact that it is so basic library,
> before you even try to get to a formal review you need:
>
> (a) Rewrite documentation making it very clear what every thing does
> including something that look trivial to you as copy constructor:
> restrictions, relationships, behavior what it does etc.
> (b) If it is your own design/research of concept say it explicitly,
> otherwise provide references to books, research papers that discuss
> root pointer algorithms

It is my own research so I have 0 reference to include.

> (c) Describe the algorithm in much wider manner including better
> examples, values of reference counters etc.
> (d) Provide much wider beginner tutorial with samples

It sounds like I am going to have write a book on the subject.  Any 
expert is welcome to help me out because if that is the case that will 
take me some time to write down.

> It looks interesting but for something that basic documentation isn't
> even 1/2 ready.

Thanks for your help it is much appreciated.