RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable ) (original) (raw)
David Holmes david.holmes at oracle.com
Tue Jan 24 02:46:42 UTC 2012
- Previous message: RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Next message: RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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
- Previous message: RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Next message: RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]