Re: [Gc] Question on avoiding data races (and compatibility with Mono)
ivmai at mail.ru
Fri Sep 11 11:35:21 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> I'd probably add a GC_get_heap_size_inner() which doesn't lock, and is called by GC_get_heap_size(). They should both be externally visible. If Mono is the only client for the former, I might not even document it in gc.h.
A good idea except that:
- not only GC_get_heap_size_inner() but also the friends (at least for GC_get_free_bytes);
- I think it would be good to export them properly (GC_API+GC_CALL) in some public header (not gc.h but, say, gc_mark.h which contains several such functions).
If no objections, I'll prepare the patch (in several days).
> I'm happy to make minor changes like this to support something like Mono, if it minimizes divergence of GC versions.
> > Hi!
> > It turns out that GC_get_heap_size() and friends are
> > synchronized now (at least for half a year) but as I recall
> > some projects (eg., Mono) with a modified libgc call them
> > while holding the lock (from a proprietary callback during
> > garbage collection or, even, with stopped world) - should we
> > leave all as-is (letting them solve their problems - I dont
> > see quick solution for it since it's impossible to
> > temporarily unlock before calling that callbacks) or add
> > unsynchronized GC_get_...() equivalents?
More information about the Gc