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

Joe Bowbeer joe.bowbeer at gmail.com
Mon Apr 23 13:34:23 EDT 2012

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 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<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 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/20120423/0ddc3235/attachment-0001.html>

More information about the Concurrency-interest mailing list