RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )

[David Holmes]

On 25/01/2012 4:56 AM, Doug Lea wrote:
> Sorry for delay; swamped...
>
> On 01/24/12 06:00, Chris Hegarty wrote:
>
>>> I don't understand the purpose of handlePossibleCancellationInterrupt.
>>> Given it doesn't clear the interrupt state why does it need to wait?
>>
>> Yes, this is true. I can't see any need for it to wait now since it
>> doesn't
>> clear the threads interrupt state. I felt this was more of a
>> marker/place holder
>> to determine the correct course of action here.
>
> The underlying issue is that when run() etc are directly
> invoked in the same thread as the caller, we (should? must?)
> ensure that the results of Future status method invocations by that
> caller agree with each other, even if racing with an asynchronous
> cancel/interrupt. The only possible inconsistency is the rare case
> where we know that the task will be cancelled but hasn't been interrupted

Okay I get it now.

> yet. So we just wait out the transient state. While it is
> arguably legal not to do this, adding this precaution
> will probably avoid getting a bug report about this someday.
> As the further comment mentions, it would be even
> nicer to force Thread interrupt status to agree with task status,
> but we can't actually do this, so I left a note in case
> anyone is tempted.

Expected/desired semantics here are somewhat vague.

David
-----

>>
>> Doug,
>> I added a new test for this. It fails about 1 in every 3-4 runs on
>> some of the boxes I have access to. Is this useful? Would you want to
>> take it into your CVS?
>
> Thanks. I had made some tests for this but at the moment don't see them.
> If you'd like to send me what you have, I'll locate others and
> add to the jtreg test.
>
> -Doug