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

2012-01-24 Thread 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

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

2012-01-24 Thread 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

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

2012-01-24 Thread 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

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

2012-01-23 Thread Chris Hegarty
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

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

2012-01-23 Thread David Holmes
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? Otherwise it looks okay. Thanks, David On