RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently

[Doug Lea]

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
>>>
>>
>