The simplest model is to grab the thread lock whenever thread A wants to
suspend thread B at a safepoint. While this serializes thread suspension
and can potentially be a bottleneck, let's wait until its a proven
performance problem to change this model. For thread A to be ready to grab
the thread lock, thread A must have all its java live references put in a
place where the GC will see them. Why? Because thread A may block. Once
thread A obtains the lock, it can disable suspension if it likes, reload the
java live refs and do whatever it needs but make certain it is quick and non
blocking. If thread A needs to block on some OS call, etc, it will need to
re-enable suspension and abandon the thread lock. Why? Because if thread A
blocks while holding the global thread lock, there may be deadlock or
latency problems.
Did you try the above approach? ARe there deadlocks?
I wonder if suspend_disable call can be treated as a thread lock and
if yes we do have nearly the same scheme related to stop_the_world
suspension.
Nik.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
