[Gc] Question on avoiding data races (and compatibility with Mono)
hans.boehm at hp.com
Fri Sep 11 10:51:04 PDT 2009
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.
I'm happy to make minor changes like this to support something like Mono, if it minimizes divergence of GC versions.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, September 10, 2009 11:49 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Question on avoiding data races (and
> compatibility with Mono)
> 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?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc