On 10/18/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
It seems we are not in sync.... I don't suggest changing current suspention scheme...I like it.... I'm talking about one particular case.....and still can't see any disadvantages in what I propose...
I'm really sorry that it turns like this, originally the was to 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. And I noticed that suspend_all intentionally, by design being called from suspend_DISABLE_region, not like conditions for example where safepoints are side effect. 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 have relatively the same lock; thread iterator(one being created during suspend_all) acquires tm_lock upon creation and releases it on destroy. But while running JVMTI scenarios we faced with very simple deadlock when tried to suspend threads from the one thread and enumerate from the other. And currently we release that lock after suspend and acquire it later upon enumeration. That's why I asked to list scenarios for suspend_all before adding any additional lock even on groups. Once again, I'm really sorry for such a discussion. Nik. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
