[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again
From:       Jaroslav Bachorik <jaroslav.bachorik () oracle ! com>
Date:       2013-12-23 12:42:36
Message-ID: 52B82FBC.3080704 () oracle ! com
[Download RAW message or body]

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-
[prev in list] [next in list] [prev in thread] [next in thread]