harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolay Kuznetsov" <nikolay.kuznet...@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:37:07 GMT
Evgueni, Weldon,

1) NO_COND_VARS code will go to the trash soon, see HARMONY-2269 for
details, Salikh has already prepared patches for this.

2) I agree, that this code is looks like (and there is) a workaround
to let jdwp agent proceed with its usual scenarios for breakpoints. I
will prepare testcases soon today, but in short the problem here is
the following:

1. Thread T1 is waiting on monitor M1.
2. Thread T2 calls suspend on thread T1.
3. Thread T2 calls notify on  M1
4. Thread T1 finishes waiting, acquires M1 and falls into safepoint
5. Thread T2 calls monitor enter (M1) and Blocks on M1 (deadlock)

The sequence above is how jdwp agent implement breakpoints. The
workaround we discussing preventing suspended thread from acquiring
monitor (point 4).

I'm going to write several testcases on this and will file an issue if
we fine more elegant solution (suggestions are welcome).

PS

>What if suspend is requested right after "if (self->suspend_request)
{..." statement?
The question here is how to behave if we were suspended and notified
after that but if we were first notified and then suspended it's out
of this case.


On 12/5/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> 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 <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
> >
> >
>

Mime
View raw message