On 02/04/2012 13:15, Doug Lea wrote:
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.
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.
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?
-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
