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] Thread.suspend() causes thread_native_fat_monitor.cpp::monitor_wait_impl() to give up the monitor
Date Tue, 05 Dec 2006 12:02:39 GMT
Weldon, Nikolay,

I can't grok how Thread.suspend() interact with
thread_native_fat_monitor.cpp::monitor_wait_impl(). Could you explain

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().


On 12/4/06, Weldon Washburn <weldonwjw@gmail.com> 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

View raw message