RFR 8034168: ThreadMXBean/Locks.java failed, blocked on wrong object

Erik Gahlin erik.gahlin at oracle.com
Sat Feb 22 07:56:51 PST 2014


Looks good.

/Erik

Jaroslav Bachorik skrev 2/18/14 5:22 PM:
> Please, review the following test change.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8034168
> Webrev: http://cr.openjdk.java.net/~jbachorik/8034168/webrev.00
>
> The test fails because of falsely evaluating the thread being parked 
> as actually waiting on a monitor. This is because there is no 
> difference in java thread state for those two situations. The test is 
> using Phaser for synchronization between the checked and checking 
> thread to make sure an appropriate code section is entered before 
> performing asserts. Then it checks the checked thread state and waits 
> till it becomes WAITING. Unfortunately, when Phaser needs to wait it 
> parks the thread and sets the thread state to WAITING. From now on the 
> test is in a completely random state and the result will largely 
> depend on timing - thus failing intermittently.
>
> The solution is to use an additional volatile variable to prevent 
> falsely indicating the park() induced WAITING state.
>
> Thanks,
>
> -JB-



More information about the serviceability-dev mailing list