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
