Weldon, Nikolay,
I can't grok how Thread.suspend() interact with
thread_native_fat_monitor.cpp::monitor_wait_impl(). Could you explain
this?
Here is my observations regarding monitor_wait_impl() implementation:
1) Line:197 discards previously set value of 'status' variable. What
if it is assigned to TM_ERROR_TIMEOUT value at line 193?
2) The above trick with unlocking a mutex in case of 'suspend_request'
is not zero seems like a workaround to me. What if suspend is
requested right after "if (self->suspend_request) {..." statement?
3) It was already discussed several times but I'll repeat it one more
time. It doesn't seem to be a solid (and safe) approach when a thread
with suspend state set to "disabled" calls monitor_wait_impl() and
thread's state is changed to "enabled" inside monitor_wait_impl().
Evgueni
On 12/4/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
The following code does not look right. I looked in the JVM spec. I can't
find any mention that a Thread.suspend() should cause the target thread to
give up any java lock. I am trying to construct a test to confirm if this
is a problem or not. Anybody have any suggestions?
line 216:
if(self->suspend_request) {
hymutex_unlock(mon_ptr->mutex);
hythread_safe_point();
hymutex_lock(mon_ptr->mutex);
}
--
Weldon Washburn
Intel Enterprise Solutions Software Division
