harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] Thread.suspend() causes thread_native_fat_monitor.cpp::monitor_wait_impl() to give up the monitor
Date Wed, 06 Dec 2006 15:45:22 GMT
Ivan,
This makes perfect sense.  One question.  Is the below protocol in the JDWP
spec?  In other words, will we hit different deadlocks when different JDWP
agents are plugged into Harmony?


On 12/5/06, Ivan Popov <ivan.g.popov@gmail.com> wrote:
>
> Evgueni,
>
> As this concerns JDWP agent algorithm, I can provide details. JDWP
> agent uses Thread.wait() to be sure that the thread is suspended in a
> right place inside JVMTI callback. The precise algorithm is the
> following:
>
> 1. Java thread T1 enters JVMTI callback and acquires M1.
> 2. Java thread T1 is waiting on M1, and thus releases M1.
> 3. Agent thread T2 acquires M1.
> 4. Agent thread T2 calls suspend on Java thread T1.
> 5. Agent thread T2 calls notify on M1.
> 6. Agent thread T2 releases M1.
> ... some debugging actions are performed which may include acquiring
> M1 by threads.
> 7. Agent thread T2 acquires M1.
> 8. Agent thread T2 calls release on Java thread T1.
> 9. Agent thread T2 releases M1.
> 10. Java thread T1 finishes waiting, and acquires M1.
> …
>
> The problem is on the step 6. After thread T2 has notified suspended
> thread T1 and released monitor M1, this monitor is eventually locked
> by thread T1, which is still in suspended state and thus should not
> lock monitor or perform any other actions. However, monitor is
> incorrectly locked by T2 for a while, and other threads hang trying to
> acquire it while performing debugging actions, or thread T2 hangs in
> step 7 acquiring monitor M1 before releasing T2.
>
> Thanks.
> Ivan
>
> On 12/5/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > On 12/5/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
> > > 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)
> >
> > Nikolay,
> >
> > I tend to think that the real problem is in the above scenario. T2
> > suspends T1 advisedly. So T2 should be ready that T1 may block while
> > holding all its monitors not only M1. (for example T1 may hold M2 as
> > well). If T2 tries to get M2 it will block on M2.....
> >
> > To have more complete understanding what is going in here I need one
> > more piece of information. To be able to perform step 3 the T2 must
> > own M1. Could you show where T2 acquires M1 and where it releases it?
> >
> > Thanks
> > Evgueni
> >
> >
> > >
> > > 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
> > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message