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

[Chris Hegarty]

On 01/24/12 02:46 AM, David Holmes wrote:
> Hi Chris,
>
> Hard to evaluate a completely new design like this as the devil is
> always in the details.
>
> 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.

That said, the previous implementation did not attempt to clear the 
threads interrupt state either. If Doug agrees that this code is 
unlikely to every be reinstated, then I think it can probably be removed.

-Chris.

> Otherwise it looks okay.
>
> Thanks,
> David
>
> On 24/01/2012 1:26 AM, Chris Hegarty wrote:
>> This issue was raised on the jdk7u-dev mailing list [1].
>>
>> The change is to update the FutureTask implementation to what is in
>> Doug's CVS. The old implementation using AbstractQueuedSynchronizer is
>> replaced with a control "state" field that is updated by CAS to track
>> completion, along with a Treiber stack to hold waiting threads.
>>
>> http://cr.openjdk.java.net/~chegar/7132378/webrev.00/webrev/
>>
>> I have already reviewed this change. The diffs in the webrev are not all
>> that useful, I reviewed it by going through the new file.
>>
>> 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?
>>
>> -Chris.
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-January/001439.html