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

David M. Lloyd david.lloyd at redhat.com
Mon Apr 23 13:10:15 EDT 2012

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> |
> Consulting Member of Technical Staff | 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> 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
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list