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

Joe Bowbeer joe.bowbeer at gmail.com
Sat Apr 21 16:33:04 EDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120421/0a384bff/attachment.html>


More information about the Concurrency-interest mailing list