Evgueni Brevnov wrote:
> Hi All,
>
> I'd like to here you opinion regarding hythread_suspend_all and
> hythread_resume_all functionality provided by TM. Actually I have to
> separate questions:
>
> 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 you see is there to prevent following deadlock scenario:
Thread A Thread B
| |
| <------------ suspend(A);
| A->suspend_request = 1;
| wait for A to reach a safepoint...
| |
suspend_all() |
B->suspend_request = 1
wait for B to reach a safepoint ...
and then two threads are infinitely waiting one another.
> 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.
We may as well leave it as the responsibility of application / TI agent
writer not to modify a suspended thread group.
Why do you think this should be enforced?
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
