[boost] Re: smart_ptr suggestion: Support decrementing shared_ptr'scount,forself-references

From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-28 11:49:04

Larry Evans wrote:
> Chuck Messenger wrote:
> [snip]
> 
>> Well, it's in too much flux right now -- perhaps if I ever finish it, 
>> I'll post it.  It's a concurrency library - an implementation of the 
>> API described in Concurrent Programming in ML.
> 
> [snip]
> 
>>
>> Thanks -- that sounds interesting, too -- I've also been told of 
>> cyclic_ptr, in the contributions.  Even if one/both don't do the job, 
>> they should give me some ideas...
> 
> I'm worried about the Concurrent part since I'm guessing that you'd
> be using threads.  

Yes.

> In that case, cyclic_ptr would have to protect
> it's phase variable (I think that's what it's called) with maybe
> a mutex.  This phase variable governs the action of the
> smart_ptr::operator=(...).  OTOH, I think (since I'm a threads
> novice ) that the stl_container.cpp I mentioned in previous post
> might be more suitable because code that calculates the "descriptors"
> used to traverse the proxy graph can be modified to execute before
> the 1st statement of main (via the construction of the static variables).
> However, that still leaves the need to synchronize the graph traversal
> during garbage collection, which could be done by a "stop-the-world"
> method, i.e. have a gc thread stop all other threads which the gc thread
> does the collection.  You might also check the reference I gave to
> terekhov_at_[hidden] which is more tuned to threads (actually multi-processing).
> The post containing that reference is at:
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1647822

I read through the paper you referenced.  It's concerned with how to 
*efficiently* do large-scale cycle detection.  I'm not even worrying 
about that phase of it -- I'm happy to just do dynamic programming to 
detect cycles.  The main problem I'm concerned with is how to build the 
object connection graph.

Once a basic "smart cyclic pointer" framework was established, then it 
would be possible to soup up the implementation, as needed, without 
affecting code which uses the framework.

But thanks for the references!

     - Chuck