[Gc] GC_get_bytes_since_gc locks

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Wed Aug 24 07:35:20 PDT 2011

On Wed, Aug 24, 2011 at 3:05 PM, Ivan Maidanski <ivmai at mail.ru> wrote:

> But what should we do?
> Three variants:
> A. Make the getter unsynchronized again (after 2 years of being
> synchronized) but this would break some clients expecting no race (or
> expecting nothing since they are not aware of a potential race here);

Which means they are broken and were already broken back in the past or the
documentation was not clear.

A'. Revert to original status and state in the header that those functions
are not data safe and set the burden on the users. You have already made
this choice for other functions.

Regarding the two years age of the locking change, I am not sure this figure
is relevant. This synchronization feature lives only in 7.2alpha tarballs
and in the CVS repository. Are we to consider them as references? When I
last checked, Debian, FreeBSD, OpenBSD relied on 7.1 or 7.0 or even earlier
versions. ECL has been shipping 7.1 for a long time due to the lack of
stable releases and only now because of the OS X Lion problems did I have to
work with the unstable sources.

B. Make the getter (and the other ones) lock-free but then every access
> inside BDWGC should be changed to use AO store/getter primitives (thus
> resulting in worse compiler optimization);
> C. Add _inner lock-free getter (to be use only from the GC call-backs).

C is inconsistent due to some functions being locked and some not. It makes
it also unpredictable for the user to know which and why. It makes software
backwards incompatible now and also if you decide in later versions to
switch some other functions from non-locking to locking.

D. (Which I mentioned in my previous email and compatible with A') Make
functions _lock() or _safe() that lock explicitly, thus warning the user.

Probably, there's a 4th alternative to change the logic of your app to make
> it independent of whether the getter is synchronized or not.

This is not possible, as I explained in my previous email. The only reason
why I need this getter is because I need to gather statistics about
allocated bytes and this has to be done in the garbage collector hook before
the counter is erased. The only way for this 4th alternative is simply to
renounce to this function and do our own counter, with the performance loss
this implies.

I any case this is just my opinion, my 2c. I am really grateful for the
existence of the BDWGC library and for the work both Hans Boehm and you have
put on it. Without this huge effort software such as ECL would not exist at

On the other hand I understand that academic rigor should be taken with a
grain of salt. Simplicity and consistency is always preferable, given
sufficient documentation and clear contracts.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20110824/13beb260/attachment-0001.htm

More information about the Gc mailing list