Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of evgueni.brevnov@gmail.com
 designates 72.14.204.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eWhaDnnjtknqU8bbSuQUPw1elF+oynMUv1xxoXVevW8KlHitiV+8Eokx8UBD/hCU6OvaJVMJgLF0lrETlQ462+eQlEINJwIrfUS3gAnreG8x9zRLfgxF9GTVZvDE2uABHLlVqrsNBFThnjo7YCfJ+GZn8ON7opiRyzkUxYICEFM=
Message-ID: <e29119980610172357p6012fdf5k1c450aaeb66dc84f@mail.gmail.com>
Date: Wed, 18 Oct 2006 13:57:59 +0700
From: "Evgueni Brevnov" <evgueni.brevnov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][threading] Is it safe to use hythread_suspend_all and
 hythread_resume_all?
In-Reply-To: <4dd1f3f00610170844j23fdf42el6d2a8641966ad5fa@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e29119980610170130p1a050b25q61e22059626a770e@mail.gmail.com>
	 <8ce6aa550610170827h2ab49d96i594aad8c4dd120c1@mail.gmail.com>
	 <4dd1f3f00610170844j23fdf42el6d2a8641966ad5fa@mail.gmail.com>

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