RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again

[Martin Buchholz]

In the past, when I've needed to check for thread state and have to wait
while staying in RUNNING, I just spin instead of sleeping, e.g.
AtomicInteger count = ...0
count.increment
whlle (count.get() < 2) Thread.yield();

which works well in tests, although of course not appropriate for "real"
code.


On Mon, Dec 23, 2013 at 4:42 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> Please, review the following test fix:
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8030847
> Webrev: http://cr.openjdk.java.net/~jbachorik/8030847/webrev.00/
>
> The root cause of the intermittent failures of this test is the fact that
> there is a lot of hidden places in JDK classes when the checked thread can
> get BLOCKED - and it will distort the blocked count and the test will fail.
> The ones identified in this case were:
>
> - ThreadMXBean.getThreadInfo()
> - System.out.println()
> - Phaser.arriveAndAwaitAdvance()
>
> Whether the thread gets blocked or not depends on many variables and this
> makes the failure very intermittent.
>
> The fix consists of:
> - not using ThreadMXBean.getThreadInfo() from within the tested thread
> - not using System.out.println() (or any other kind of output) in the
> tested thread
> - not using Phaser to synchronize the tested thread and the control thread
>
> The toughest part is to replace Phaser for the synchronization purposes
> with a similar construct which would not block the thread when waiting for
> the other party. CyclicBarrier didn't work either as probably wouldn't not
> any other solution based on java.util.concurrent locks.
>
> The TwoPartySynchronizer provides the block-free synchronization and is
> based on atomics and Thread.wait(). It is not a general purpose replacement
> for Phaser or CyclicBarrier but it works very well for exactly two parties
> needing progress synchronization and not wanting to block any of the
> parties.
>
> Thanks,
>
> -JB-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140103/39f1cf2a/attachment.html