Hi.
I've created HARMONY-4905.
Test case attached.
Alex.
On 10/6/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> Alexander,
>
> Would it be possible for you to write a simple test that demonstrates
> the inconsistent behavior?
>
> On 10/5/07, Alexander Alexeev <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
