[Gc] Question on avoiding data races (and compatibility with Mono)

Boehm, Hans 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)
> 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?
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list