Re: [boost] concurrent garbage collector

Subject: Re: [boost] concurrent garbage collector
From: Taylor Holliday (taylor_at_[hidden])
Date: 2013-06-20 00:42:27

Hi Anthony,

  Thanks for taking a look! RootPtr<T> automates the work of AddRoot and RemoveRoot... is that what you're after?

For AddEdge and RemoveEdge, I'm thinking of writing an EdgePtr<T>. One issue is that an EdgePtr could be destroyed during collection, so the EdgePtr's destructor would have to check to see if its being called from the collector thread to avoid spurious RemoveEdge calls. Maybe there's a better way to do that than with thread-specific data.

  The situation where this GC is easier to use is when you have cycles that aren't easily broken using weak_ptr. This is the case in my app, where the user can create cycles in the graph (resulting in leaks if using shared_ptr). Using weak_ptr for all edges of the graph just creates another situation of manual memory management.

cheers
- Taylor

On Jun 18, 2013, at 10:32 PM, Antony Polukhin wrote:

> 2013/6/18 Taylor Holliday <taylor_at_[hidden]>:
>> Hey Boost,
>> 
>>  After struggling with breaking shared_ptr cycles in my app, I wrote a little concurrent garbage collector which uses boost::lockfree::queue. Its actually fairly general purpose, and I've released the code here:
>> 
>> https://gist.github.com/wtholliday/5793270
>> 
>> Inspired by my question on stack overflow:
>> 
>> http://stackoverflow.com/questions/17116189/concurrent-garbage-collection-for-a-c-graph-data-structure
>> 
>> I'm also working on releasing my unit test... its just quite dependent on other code.
>> 
>> For the interface: the basic idea is you have a RootPtr<T> used to manage the collector's root set (please forgive my propensity for CamelCase). You have to explicitly manage references between collectable objects (via AddEdge and RemoveEdge functions), but I think that could be made safe using another smart pointer type which knows the collectable object which owns it. At this point I'm not too concerned about performance, as my object graphs aren't that big. I bet a GC guru could implement this without using a queue of events.
>> 
>> Anyway, this is the kind of thing I'd love to see in boost someday, so it would be great to read your opinions of it :-)
> 
> Looks good at first glance.
> 
> It would be good to automate work with RemoveRoot/AddRoot somehow. For
> example RemoveRootAtScopeExit and AddRootAtScopeExit structures could
> be added.
> 
> But usability of this solution looks worser than shared_ptr/weak_ptr.
> Managing reference counting using
> RemoveRoot/AddRoot/RemoveEdge/AddEdge looks harder that declaring
> shared_ptr/weak_ptr variable. Can you give some example when GC is
> easier to use?
> 
> --
> Best regards,
> Antony Polukhin
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost