guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gc issues


From: Michael Livshin
Subject: Re: gc issues
Date: 19 Sep 2000 15:18:53 +0300
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Dirk Herrmann <address@hidden> writes:

> > you may need interlocking between mutators and the GC, but
> > there's no reason to require interlocking between mutators themselves
> > -- you'll just serialize all allocation this way.
> 
> Hmmm.  I am not (yet) an expert with threads, but it seems that, in order
> to do this, you would need a separate mutex for every thread that is
> running.  Not a big problem, though:  You could have a global list of
> thread mutexes for gc.  Every thread locks its own mutex to obtain a new
> cell from its private pool, while gc has to lock them all.  Maybe, gc has
> only to lock the one for the thread the stack of which is is currently
> scanning?  This would allow other threads to run during gc until their
> private cell pool is empty.

hmmm...  I'm afraid that the situation is much hairier.  I'm not an
expert in concurrent GC, so I'm taking the conservative option to just
be very very afraid of it ;).

after all, you can't easily predict what will happen if you let your
threads run and modify things on the heap while you are trying to
collect garbage.  all I can think of is some really entertaining
races.

so I'd rather opt for stopping all running threads (regardless of
whether they allocate stuff or not) prior to doing GC.

> Still, am I right saying that due to the multiprossor issue we _need_
> locking to obtain a new cell?  Or am I missing something?

simplistically, yes.  really, not always.

in fact, the (supposedly) most common allocations (for pairs and
closures) don't need locking -- you just have to scan cdrs of
freecells conservatively.  the rest needs locking, but hopefully it's
OK.

in general, the guideline should be this: if the way of scanning the
cdr depends on the info in the car, then lock.

I hope this was coherent,
--mike

-- 
"Tools that are no good require more skill."



reply via email to

[Prev in Thread] Current Thread [Next in Thread]