RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )
david.holmes at oracle.com
Tue Jan 24 20:22:20 PST 2012
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
>> 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.
>> 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.
More information about the core-libs-dev