[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)
David M. Lloyd
david.lloyd at redhat.com
Mon Apr 23 13:45:08 EDT 2012
To put it another way - I have extensively used Future-like objects
which have three result methods: setResult(T result),
setFailure(Exception cause), setCancelled(), each returning a boolean.
The first one called returns "true", the latter ones return "false".
This hugely simplifies asynchronous cancellation logic. Yes there are
non-sane invocation possibilities but the results are always
deterministic, and it works pretty well in practice.
On 04/23/2012 12:34 PM, Joe Bowbeer wrote:
> I disagree as well. I use futures a lot (and in addition to using
> FindBugs, I write my own custom FindBugs detectors:-)
> For me, ignoring duplicates is better than throwing an exception.
> The simplest use case is when the value is canceled by the owner and
> then subsequently set by a worker. Cancel wins.
> Or when the value is farmed out to several competing strategies, and
> first one to answer wins.
> The boolean result of the set methods is symmetric with the boolean
> result of cancel.
> On Mon, Apr 23, 2012 at 10:10 AM, David M. Lloyd wrote:
> I disagree. May times using set() on an object like this is the
> point of coordination. Would you throw an exception if
> putIfAbsent() failed?
> On 04/23/2012 11:37 AM, Nathan Reynolds wrote:
> Consider throwing an exception instead of returning false. The
> will force the caller to deal with the already set condition.
> false is a bug waiting to happen.
> Calling set() twice usually indicates a larger bug in the caller
> Why would the algorithm call it twice? Is there a race between 2
> 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
> deal with the result of the java.io.File and
> APIs. For many that don't use FindBugs, they will have a lot of
> Nathan Reynolds
> <http://psr.us.oracle.com/__wiki/index.php/User:Nathan___Reynolds <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>>
> 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
> classes I'm redoing over and over again in most of the
> Implementing it directly on top of AQS might provide
> some benefits
> comparing to extending from FutureTask? Oh wait, it
> smells like
> 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
> plus setException(). In other words, I envision FutureValue as a
> Future with two additional methods: boolean set(v) and boolean
> Are there any other Future enhancements that you think are
> needed in j.u.c.?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest