Hi Jaroslav,
On 23/12/2013 10:42 PM, Jaroslav Bachorik 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.
I see you actually meant Thread.sleep, which does of course block the
thread but doesn't put it into the problematic "blocked" state that
affects the blocked-count. That said I don't understand why this problem
exists given that by definition the use of any of the synchronizers
(based on park()) should not affect the blocked count:
getBlockedCount(): Returns the total number of times that the thread
associated with this ThreadInfo blocked to enter or reenter a monitor.
None of CyclicBarrier/Phaser etc are monitors, so the BlockedCount
should not be being updated. If it is then that is a spec or
implementation bug in itself :(
David
