harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Date Wed, 18 Oct 2006 06:57:59 GMT
Weldon,

I agree with what you are saying above..... Do you think it makes
sense to call hythread_suspend_all in enabled state only?

Evgueni

On 10/17/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message