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

[Martin Buchholz]

Not checking any details, but tests that want to wait for a particular
thread state are a good reason to use

volatile boolean flag;
...
while (!flag) Thread.yield();

I prefer calling Thread.yield to sleeping in this special case, in part
because I don't want to rely on the implementation of sleep, while yield is
semantically a no-op.  (Also sleeping 100ms is a long time for a computer)



On Tue, Feb 18, 2014 at 8:22 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> 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-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140218/9f0cd912/attachment.html