harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy" <pavel.reb...@gmail.com>
Subject Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Date Mon, 08 Oct 2007 07:05:34 GMT
+1

On 06/10/2007, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> Alexander,
>
> Would it be possible for you to write a simple test that demonstrates
> the inconsistent behavior?
>
> On 10/5/07, Alexander Alexeev <alexander.n.alexeev@gmail.com> wrote:
> > Pavel, looking on the code I can't understand why different events are
> > sent just before wait thread is blocked inside lock.wait(). In both
> > cases JVMTI_EVENT_MONITOR_WAIT should be sent, there is no contention
> > for monitors on enter to lock.wait().
> >
> > Is wait thread blocked inside lock.wait() before waited thread
> terminated?
> >
> > Maybe you misunderstand me.
> > Lets define two threads :)
> > T1 - long running job
> > T2 - is waiting for T1 termination
> >
> > I am interested in event which is rose just after T2 calls join method
> > for T1, and T1 still continue execution and T2 become blocked and
> > wait.
> >
> >
> > > 2. Should it be? What is proper thread's state depiction?
> > I think it should. Proper state is "wait" because it corresponds with
> > expectation about what is happening with thread, it is waiting another
> > termination but isn't competing for monitor.
> > Also it corresponds with other VMs behavior.
> >
> > Thanks.
> > Alex.
> >
> > On 10/5/07, Pavel Rebriy <pavel.rebriy@gmail.com> wrote:
> > > Hello Alexander
> > >
> > > Here is an instance of  Thread.join() implementation:
> > >
> > >     public final void join() throws InterruptedException {
> > >         synchronized (lock) {
> > >             while (isAlive()) {
> > >                 lock.wait();
> > >             }
> > >         }
> > >     }
> > >
> > > If joined thread is dead we don't go to wait and the last event is
> > > JVMTI_EVENT_MONITOR_CONTENDED_ENTER. In case of the following code:
> > >
> > >     public final void join() throws InterruptedException {
> > >         synchronized (lock) {
> > >             do {
> > >                 lock.wait();
> > >             } while (isAlive());
> > >         }
> > >     }
> > >
> > > the last event will be JVMTI_EVENT_MONITOR_WAIT. So the answers are:
> > >
> > > 1. No, such kind of behavior is not defined in spec.
> > > 2. Should it be? What is proper thread's state depiction?
> > >
> > >
> > > On 05/10/2007, Alexander Alexeev <alexander.n.alexeev@gmail.com>
> wrote:
> > > >
> > > > Hi, All.
> > > >
> > > > I've faced the following difference in Harmony JVM TI behavior in
> > > > comparison with other JVMs.
> > > >
> > > > When one thread spawns another and joins it, waiting for its
> > > > termination, it becomes blocked on monitor  (from last handled event
> > > > JVMTI_EVENT_MONITOR_CONTENDED_ENTER for that thread before 'sleep")
> ,
> > > > while in other VMs (Sun's, IBM's and BEA's) thread which calls
> "Join"
> > > > starts waiting (last event is JVMTI_EVENT_MONITOR_WAIT before
> > > > 'sleep"). Probably set of events depends on VM internals, but in
> > > > common sense "waited" state is more suitable for thread which waits
> > > > for other thread termination.
> > > >
> > > > 1. Can such kind of behavior be defined in any specs?
> > > > 2. Could it be fixed, i.e. from blocked to waited state during join?
> > > > This is required for proper thread's state depiction in tools.
> > > >
> > > > Alex.
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Pavel Rebriy
> > >
> >
>
>
> --
> Weldon Washburn
>



-- 
Best regards,
Pavel Rebriy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message