RFR 8034168: ThreadMXBean/Locks.java failed, blocked on wrong object (original) (raw)

Martin Buchholz martinrb at google.com
Tue Feb 18 09:06:39 PST 2014

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

More information about the serviceability-dev mailing list