Re: [boost] concurrent garbage collector

Subject: Re: [boost] concurrent garbage collector
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2013-06-19 01:32:17

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