On 18.10.2013 18:42, Mandy Chung wrote:
On 10/16/2013 7:18 AM, Jaroslav Bachorik wrote:
Please, review this simple test change.
The test tries to get the number of times a certain thread was blocked
during the test run and intermittently fails with the difference of 1
- the expected number is 4 but the reported number is 3.
When updating the thread statistics (the blocked count in this case)
no lock is used so there might be stale data when the ThreadMXBean
retrieves the stats. The patch tries to workaround this problem by
retrying a few times with the added delay. The test will try to obtain
the correct result for at most 10 seconds - after that it will fail if
the retrieved blocked count does not equal the expected blocked count.
Issue : https://bugs.openjdk.java.net/browse/JDK-7197919
Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00
Looks okay. I notice that existing code that catches
InterruptedException only sets testFailed to true but continue. I think
it might be good to fix them to return if IE is caught to fail-fast like
what your fix does.
Unfortunately, it's not possible to directly return in those cases. The
synchronization logic relies on the code passing through all the
"signal"/"waitForSignal" pairs for the test to finish - otherwise the
test might just hang. I have at least added loop breaks to fail a bit
faster in case of IE.
-JB-
Mandy
