On 10/17/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> 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.
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.
> 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 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.
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?
Thanks
Evgueni
Thank you.
Nik.
> Thanks
> Evgueni
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
