RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently (original) (raw)
Doug Lea dl at cs.oswego.edu
Tue Apr 3 23:23:20 UTC 2012
- Previous message: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently
- Next message: jtreg, junit, and testng (was Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 04/02/12 08:46, Chris Hegarty wrote:
I think you are both right -- the main thread must delay but need not re-interrupt. Yes, re-interrupting is not ideal, but it looks like Phaser.awaitAdvanceInterruptibly differs from say CyclicBarrier.await. CyclicBarrier.await is spec'ed to throw IE is there is a pending interrupt when it is called. Is this the expected behavior of Phaser.awaitAdvanceInterruptibly too? I was assuming not, that is why I tried to have interrupt invoked after the thread blocked in awaitAdvanceInterruptibly.
It will only check interrupt if it would otherwise wait, but it doesn't consume the interrupt in any case, so one interrupt should be enough in all the scenarios that can occur in that test.
On the test side it may be sufficient to just delay/sleep the main thread for 2 seconds before call interrupt. I think this is what you are suggesting, right?
Yes.
-Doug
-Chris.
-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
- Previous message: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently
- Next message: jtreg, junit, and testng (was Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]