gcj crashes if a user-thread gives up its rights
Tue Dec 14 16:39:00 GMT 2004
Jost Boekemeier wrote:
>On Mon, 2004-12-13 at 18:17, Bryce McKinlay wrote:
>>It would be interesting to know how these other VMs solved the issue.
>Mediator pattern. The mediator still runs with the appropriate
>privileges. I guess GCJ already has a mediator which iterates through
>the list of threads and stops each of them when the user-thread's GC
>wants to run. The only thing that seems to fail is the command that the
>user-thread's GC sends to the mediator.
In the current code, there isn't a separate "mediator" thread - any user
thread which the GC happens to run in will try to call pthread_kill to
suspend the other threads.
>>Is there is another IPC mechanism with the necessary semantics - ie able
>>to suspend any thread at any time, asynchronously?
>I think this should not be necessary. The mediator waits for commands
>anyway, so a simple pipe would be sufficient. Even a condition variable
>will work. So we only have to change the pthread_kill() into a
That wouldn't work, because pthread_cond_signal() won't interrupt a
thread that isn't actually waiting on the right condition variable.
You'd still have to either use pthread_kill() or have the compiler
insert interrupt points at each basic block edge. The later would have a
performance effect and would be tricky to implement in the presence of
blocking IO, etc.
What may work, however, is instead of sending the pthread_kill's from
whichever thread the GC happens to occur in, dedicate one, always
privileged thread to sending the pthread_kill's and running the GC.
Suspended threads could then enter a pthread_cond_wait() waiting for the
restart signal from the collector thread.
More information about the Java