RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

[Mandy Chung]

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-