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

[Chris Hegarty]

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