Re: concurrent garbage collection and POSIX threads

If you can't count on cooperation from the threads themselves,
it still seems that the signal-based approach is the best you can do.
But you have to be careful what calls you make from the signal handlers;
locks and condition variables are not async-signal-safe.

For the way we do this, see the code around GC_suspend_handler_inner
in

http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/pthread_stop_world.c?revision=1.29&view=markup

This is probably still not 100% portable, but somewhat close.

Hans

On Thu, 7 Jan 2010, Jon Harrop wrote:

> On Wednesday 06 January 2010 06:14:30 you wrote:
>> I'm attempting to implement a concurrent garbage collector (specifically
>> the Huelsbergen-Winterbottom VCGC algorithm) for a small compiled
>> language I'm working on and they it requires that one be able to pause
>> execution of all running threads during a barrier synchronization event
>> at the end of a garbage collection epoch, and then resume execution of
>> these threads afterwards.  I believe many other concurrent garbage
>> collection algorithms have similar requirements.  How would one
>> implement this using POSIX.1b/1c primitives alone?
>
> I just implemented this in HLVM:
>
>  http://forge.ocamlcore.org/projects/hlvm/
>
>> The pause and resume
>>  are in general asynchronous.  I've thought up a rather convoluted
>> method that involves adding a signal handler for each thread, which upon
>> receipt of a POSIX real time signal, does a wait on a condition
>> variable.  When the thread is to be resumed, the condition variable is
>> signaled, causing all threads waiting on it to resume execution, at
>> which point the signal handler returns and execution resumes.
>>
>> I wonder if there is an easier way to do this that does not require
>> these kinds of contortions.   There are thr_suspend/thr_resume calls in
>> Solaris, and in older versions of Linux using LinuxThreads it was
>> possible to use SIGSTOP/SIGCONT on the thread ID, but with NPTL, which
>> is now fully POSIX-compliant, the use of those signal would stop all
>> threads, which I do not want.  Any hints from those who have implemented
>> such garbage collectors?
>
> I just used locks with thread-local state including running/suspended and
> thread global run/suspend state. Any thread that incurs a GC sets the global
> target state to suspend and waits until all thread-local states
> are "suspended" before doing the GC and setting the global state back
> to "run" whereupon the other mutators set their own states to "running" and
> resume.
>
> The only non-trivial aspects are making sure states are changed atomically
> when they should be and using blocking sections to handle blocking calls,
> such as joining with another thread, to avoid dead locks.
>
> -- 
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
>