[Gc] GC_get_bytes_since_gc locks

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Tue Aug 23 14:58:41 PDT 2011


On Tue, Aug 23, 2011 at 8:29 PM, Boehm, Hans <hans.boehm at hp.com> wrote:

>  In general, yes, it is necessary.  See for example my HotPar 2011 paper:
>  http://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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20110823/4b1abc7f/attachment.htm


More information about the Gc mailing list