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

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


My subjective opinion.  And in that same opinion, a set() is a similar 
CAS-flavored operation.

On 04/23/2012 02:51 PM, Kirk Pepperdine wrote:
> what makes this case exceptional?
>
> On 2012-04-23, at 7:33 PM, David M. Lloyd wrote:
>
>> If you call putIfAbsent but the key is already mapped, then the put fails and the old value is returned instead.
>>
>> On 04/23/2012 12:31 PM, Kirk Pepperdine wrote:
>>> define failure for putIfAbsent???
>>>
>>>
>>> On 2012-04-23, at 7:10 PM, 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>   |
>>>>> 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
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>>
>> --
>> - DML
>


-- 
- DML


More information about the Concurrency-interest mailing list