Hi Jaroslav,
Like Daniel and David said, CyclicBarrier and other j.u.concurrent
utility seem a good replacement with the ThreadExecutionSynchronizer
class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
added to the platform (both java.util.concurrent and
java.lang.management were added in JDK 5). Later
ThreadExecutionSynchronizer was added to fix some intermittent issue.
I think it's worth the investigation to replace the existing logic with
j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
by a few other tests).
Mandy
On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
Please, review the following patch of the intermittently failing test:
http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
Sometimes the ThreadExecutionSynchronizer class failes to achieve the
desired synchronization (due to possible data races when evaluating and
setting the "waiting" variable) leading to test failures.
The patch fixes the possibility of data race. Also the Locks class is
tidied up a bit.
Thanks,
-JB-
