[gclist] Thread safe GC

Jerry Leichter leichter@smarts.com
Mon, 14 Apr 1997 17:23:00 -0400


| > If I can't stop and restart threads I'm totally stuck. I can't really
| > collect for running threads.
| 
| I'm speculating here, but, in theory, shouldn't you be able to
| collect in the multithreaded situation using thread priorities ?
| 
| What i mean is, at the start of the collection, raise the priority
| of the collector thread to n+1 (where n in the previous highest
| priority, and high n = high priority), and scan the stacks of threads
| at piority n. When all stacks at priority n have been scanned, lower 
| the collector thread to priority n and start scanning the stacks 
| priority n-1.
| 
| This wouldn't require the ability to stop threads, but if non-gc threads
| changed their priorities, you'd be lost.

What happens when you run on a true multiprocessor?  Sure, the collector has the 
highest priority and so grabs one processor for itself.  But other other threads 
happily run on the other processors, and the whole thing falls to the ground in 
a clatter.

Priority as a tool for synchronization is fine for uniprocessors; it doesn't 
have much applicability to multiprocessors.

You are, however, focusing on the real issue:  The GC thread needs some way to 
say "Run me, and no one else."  This isn't a primitive thread packages typically 
give you - and it's extremely messy to build on top of the primitives you *do* 
get.  For example, there's no such primitive in pthreads, which is become 
something of a standard, and I don't think there's any pthreads-generic way to 
implement it.  Yet another example of C/C++ damage to computing!  This kind of 
primitive isn't particularly useful to applications other than GC (for a simple 
reason:  It's a very non-modular thing to want.  In general, you expect threads 
to be independent of each other except when they explicitly synchronize.  But 
the GC and GC'ed memory is inherently shared among all threads, even those 
written by completely independent developers for independent purposes.)  Since C 
an C++ (and FORTRAN - pthreads contains stuff for parallel FORTRAN compilers to 
emit) don't have garbage collection, and it was the C/C++/FORTRAN community that 
produced the pthreads spec.
							-- Jerry