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][jvmti] Thread's state after Join invocation is debatable
Date Sat, 06 Oct 2007 15:34:03 GMT
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

Mime
View raw message