RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently (original) (raw)

Doug Lea dl at cs.oswego.edu
Mon Apr 2 12:15:01 UTC 2012

On 04/02/12 07:28, David Holmes wrote:

On 30/03/2012 9:22 PM, Chris Hegarty wrote:

Sorry guys, I think I found the actual cause for this failure. Though I think the increased defensive timeouts are still a good idea.

There is a race in the test itself. The "One thread interrupted" test tries to interrupt a thread blocked in awaitAdvanceInterruptibly, but how do we know the thread has actually made it to this point before we interrupt? The usual situation with these kind of tests! I don't think we're meant to. The interrupt will remain pending and only cause the IE when it does reach awaitAdvanceInterruptibly. It is the thread doing the interrupting that needs to wait until the interrupt has been received - but I don't think it needs to re-interrupt as that implies the interrupt is being lost somewhere.

I think you are both right -- the main thread must delay but need not re-interrupt.

-Doug

David

The solution is to retry the interrupt if we know the target thread hasn't thrown anything.

http://cr.openjdk.java.net/~chegar/6963841/webrev.01/webrev/ -Chris.

On 27/03/2012 11:58, Doug Lea wrote: On 03/26/12 23:04, Chris Hegarty wrote: David, Doug,

This test has been failing intermittently on jdk7u-dev and jdk8 for a while now. It only appears to fail when run in our internal build/test system (JPRT). I believe the cause of the failure to be simply that the machines the test is run on are too slow, or very busy, and the defensive timeout in the test are not large enough to handle this. The solution is to increase these timeout (similar to other tests in the concurrency area that we increased the timeouts for too).

OK. I synced with our version. As always, it is too bad that there is no way to operationalize the notion of "for some timeout value appropriate for the platform, no TimeoutExceptions occur". -Doug

More information about the core-libs-dev mailing list