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 Tue, 05 Dec 2006 14:55:29 GMT
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)
>
> The sequence above is how jdwp agent implement breakpoints.


That's what I was looking for.  A reason why T1 would see a suspend request
immedately followed by a notify.  It seems possible that jdwp would do
something like this.


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