harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Date Tue, 17 Oct 2006 15:44:14 GMT
On 10/17/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
>
> Hello All,
>
> first of all I'd like to emphasize that suspend/resume_all functions
> are potentially unsafe
> and should be used with care.


In specific, with a solid model of system behavior in mind.

secondly, those methods were designed mainly to support
> stop_the_world_enumeration
> and thus usually being used under certain conditions.
>
> > 1)  I found that hythread_suspend_all calls thread_safe_point_impl
> > inside. There is no assertion regarding thread's state upon entering
> > hythread_suspend_all. So it can be called in suspend disabled state
> > and nobody (at least me) expects to have a safe point during
> > hythread_suspend_all.


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?


The problem seems to be very similar with the
> > one discussed in "[drlvm][threading] Possible race condition in
> > implementation of conditional variables?" Your thoughts?
>
> The code of suspend_all method is dedicated to the cyclic suspension
> problem.
> The fact that this method is being called from suspend_disable region and
> have safe_point in within is all about cyclic suspension. A lot of
> time was spent to resolve deadlocks cause by two threads trying to
> suspend each other.
>
> I agree that problem is similar to one with conditions, but I believe
> that this one should be discussed as a part of particular scenario.
>
> > 2) Assume I need to suspend all threads in particular group. Ok I pass
> > that group to hythread_suspend_all. Later when all suspended threads
> > should be resumed I pass the same group to hythread_resume_all. But
> > threads were suspended group has changed. For example one new thread
> > was added to it. So the questions are. Is it acceptable to have such
> > "unsafe" functionality? Would it better to lock the group in
> > hythread_suspend_all and unlock it in hythread_resume_all.
>
> First of all I would differentiate j.l.ThreadGroup and thread groups
> defined by thread manager(saying that I mean that this method was not
> designed for ordinary use, like ThreadGroup.suspend()), and after that
> return to the question why we would need it (I mean, it would be
> better to have particular scenario) and then we can discuss how to
> implement this. Till now suspend_all method was designed to work
> within one group(in particular default group, containing java
> threads), and called be GC.
>
> Thank you.
>   Nik.
>
> > Thanks
> > Evgueni
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message