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 11:59:15 GMT
Hi Nikolay!

On 10/18/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
> Evgueni,
>
> > > first of all I'd like to emphasize that suspend/resume_all functions
> > > are potentially unsafe
> > > and should be used with care.
> > >
> > > secondly, those methods were designed mainly to support
> > > stop_the_world_enumeration
> > > and thus usually being used under certain conditions.
> >
> > hmmm... it is strange to hear words like that. TM provides
> > specification for this particular method and it should perform
> > according to that specification. I as a developer don't want to care
> > about particular use case scenario.
>
> I'd say that w/o stop_the_world enumeration we would not include this function
> to the interface, and w/o Thread,stop()(which is deprecated and
> jvmtiThreadStop which is
> used in debugger) we would not include even suspend function to the
> interface, like pthread or original version of hythread.
>
> Most of the others implementations have some special notes about suspend:
> MSDN:
> "This function is primarily designed for use by debuggers. It is not
> intended to be used for thread synchronization."
>
> HP pthread_suspend_np(not portable):
> "This functionality enables a process that is multithreaded to
> temporarily suspend all activity to a single thread of control. When
> the process is single threaded, the address space is not changing, and
> a consistent view of the process can be gathered."
>
> So, this function is unsafe, and should be used with care and "In
> specific, with a solid model of system behavior in mind."(c) Weldon;

I agree it is required to have a solid model in mind. I also believe
it is required to have such design/implementation which doesn't allow
to break that model.

>
> And returning to the question of safepoints inside suspend_disable
> regions, we have a lot
> of such places inside a VM and suspend_all is probably the only place
> where this safepoint was left intentionally(I mean cyclic suspends).

It's ok to have safe points inside disabled regions only if it is
really safe to enable GC at that point. All such cases should be taken
with extreme caution. In our particular case we can't guarantee that
it is safe to suspend the thread. That's why I think having something
like assert(hythread_is_suspend_enabled) in the beginning of
hythread_suspend_all is really required? Of cause it will require some
changes in VM and TM...

>
> > Nikolay, I understand there is only one use case for now. Again I
> > expect the method works according to the spec but not how it is used
> > in some particular case. Could you clarify what you mean by saying
> > "Till now suspend_all method was designed to work within one group(in
> > particular default group, containing java
> > threads), and called be GC." Why do you have such restriction? Where
> > it is specified?
>
> We have such restrictions, because it's extremly hard to implement
> common(not only for GC + limited use of TI). The spec on
> suspend/suspend_all function usage scenarious can be found at:
> drlvm/trunk/vm/thread/doc/ThreadManager.htm paragraphs 6.2 and 6.3

Could you give the most impossible thing to do? I was thinking of TM
as of quite independent component. But now it seems like some parts of
it are really depend on DRLVM implementation. :-(

Thanks
Evgueni

>
> Thank you.
>   Nik.
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message