[Gc] GC_get_bytes_since_gc locks

Boehm, Hans hans.boehm at hp.com
Tue Aug 23 16:21:46 PDT 2011

It sounds like we can agree on a few things here:

1.  We probably want both the locked and unlocked accessors here.  The naming is more contentious.

2. We're not currently 100% consistent, and probably can't be.

My concern with having the default GC_get_bytes_since_gc() unlocked is that this is a function that is moderately likely to be called directly by the user to determine, for example, whether to invoke an explicit collection.  In that case, having to lock explicitly seems unnatural to me, since you'd have to explicitly use very obscure functionality, namely GC_call_with_alloc_lock(), in order to avoid the problem.

GC_get_gc_no() is arguably similar, though it seems less likely to me to be called directly from the application, outside a callback.

The others are somewhat different, since the values change only in response to user calls.  Hence the user can far more easily provide for mutual exclusion.  Those seem fine to me as they are.  And most of the other accessors for GC-modified data do acquire the allocation lock.

Your point about backwards compatibility in combination with callbacks is a good one, unfortunately.  Is it possible to work around the problem by calling GC_get_bytes_since_gc_inner() if it exists, and GC_get_bytes_since_gc() if it doesn't?  My guess is that very few people (hopefully only one) are affected by this.  Changing it back would I think make the interface less consistent, and probably make the most common usages of GC_get_bytes_since_gc() less likely to be correct.

Maybe GC_get_gc_no should get the same treatment as GC_get_bytes_since_gc() for consistency.


From: Juan Jose Garcia-Ripoll [mailto:juanjose.garciaripoll at googlemail.com]
Sent: Tuesday, August 23, 2011 2:59 PM
To: Boehm, Hans
Cc: gc at linux.hpl.hp.com
Subject: Re: [Gc] GC_get_bytes_since_gc locks

On Tue, Aug 23, 2011 at 8:29 PM, Boehm, Hans <hans.boehm at hp.com<mailto:hans.boehm at hp.com>> wrote:
In general, yes, it is necessary.  See for example my HotPar 2011 paper:  https://www.usenix.org/events/hotpar11/tech/final_files/Boehm.pdf .

I do not agree. The _general_ fact that arbitrary variables are not atomic w.r.t. read/write operations does not mean we have to protect all accesses with locks, that would be insane. The user also has something to say here.

If your concern is that the output of an accessor is corrupt because some other thread might write at the same time the user reads a merely informative value, then the right thing is to change the contract and create _another_ function that locks, not trying to outsmart the user by hiding the locking behavior in such a function, which now may inadvertently stop a user's thread or render some code non-reentrant.

See for instance GC_get_gc_no, GC_get_non_gc_bytes, GC_get_free_space_divisor, GC_get_time_limit ... which explicitly state that they should be called with a lock and preserve the old semantics.

Moreover, if now the change goes for a *_inner name to be the function that does not lock, this means that my code has to be changed to use this function, rendering it incompatible with previous versions of the library (<= 7.1), which are the ones installed all around.


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/20110823/afcad66a/attachment.htm

More information about the Gc mailing list