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

[Doug Lea]

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

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