[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)

Nathan Reynolds nathan.reynolds at oracle.com
Mon Apr 23 12:37:32 EDT 2012

Consider throwing an exception instead of returning false.  The 
exception will force the caller to deal with the already set condition.  
Returning false is a bug waiting to happen.

Calling set() twice usually indicates a larger bug in the caller code.  
Why would the algorithm call it twice?  Is there a race between 2 
threads in the caller code?  Is one part of the caller code not aware of 
what the other part of code did?

I raise this concern because FindBugs flags issues if the caller doesn't 
deal with the result of the java.io.File and java.util.concurrent.Lock 
APIs.  For many that don't use FindBugs, they will have a lot of bugs.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 4/21/2012 1:33 PM, Joe Bowbeer wrote:
> On Sat, Apr 21, 2012 at 12:08 PM, Aleksey Shipilev wrote:
>     Yes. SettableFuture-like class is something missing from concurrent
>     classes I'm redoing over and over again in most of the projects.
>     Implementing it directly on top of AQS might provide some benefits
>     comparing to extending from FutureTask? Oh wait, it smells like
>     another
>     API enhancement proposal? :)
> Alex,
> Bill Pugh once suggested a separate concurrency abstraction: an 
> externally settable FutureValue<V>, which supports the following methods:
>        V get() -  Waits if necessary for the value to be set, and then 
> returns the value.
>        boolean isDone() - Returns true if the value is set
>        boolean set(V v) - Sets the value if it was not already set.
>                Returns true if the value was set by this call, false if it
>                was set by another call.
> Having set(v) return a boolean seems like a good idea.  What do you think?
> To this I would also add the other Future methods such as cancel(), 
> plus setException().  In other words, I envision FutureValue as a 
> Future with two additional methods: boolean set(v) and boolean 
> setException(e).
> Are there any other Future enhancements that you think are sorely 
> needed in j.u.c.?
> --Joe
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120423/79e2cd9e/attachment.html>

More information about the Concurrency-interest mailing list