[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)
viktor.klang at gmail.com
Sat Apr 21 18:19:49 EDT 2012
On Sat, Apr 21, 2012 at 10:33 PM, Joe Bowbeer <joe.bowbeer at gmail.com> 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? :)
> 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.?
onResult + onException callbacks.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest