[Gc] GC_get_bytes_since_gc locks

Bruce Hoult bruce at hoult.org
Tue Aug 23 17:36:41 PDT 2011


On Wed, Aug 24, 2011 at 6:29 AM, 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

While there can be data races if the counter requires multiple memory
accesses to read, a lock is a very heavy-weight way to avoid them!

This problem is common when reading things such a real time clock
registers and is usually solved with a construct such as:

// depends on big/little endian
#define HIOFF 1
#define LOOFF 0

WORD *loPtr = (&counter)+LOOFF;
WORD *hiPtr = (&counter)+HIOFF;
WORD hi1, hi2, lo;
do {
  hi1 = *hiPtr;
  lo = *loPtr;
  hi2 = *hiPtr;
} while (hi1 != hi2);
return (hi1<<WORDSIZE) | lo;

If the variable is in fact a counter then the loop is very unlikely to
run more than once.

This of course can be ruined by the kind of compiler optimizations
described in your paper, in which case it can be implemented in
assembler and put in the atomic ops library.

Those super-paranoid about forward progress can switch to a locked
version if it loops too many times.

This won't deal with the kind of problem you describe where the
variable is not aligned to at least a WORD boundary and the CPU
silently does multiple reads for a WORD. I don't believe this is a
practical problem on any reasonable compiler if the declaration of the
counter variable is under your control and you refrain from bitfield
notation or other packing pragmas.  In any case it can be easily
detected and a compile or runtime error issued to prevent incorrect
results.



More information about the Gc mailing list