[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)
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? :)
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest