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

Kirk Pepperdine kirk at kodewerk.com
Mon Apr 23 16:30:01 EDT 2012


ahhh, my misunderstanding and my appologies.

Using the word exceptional shouldn't be a semantic land-mine. It has a very clear definition.

exceptional
adjective
1 the drought was exceptional: unusual, uncommon, abnormal, atypical, extraordinary, out of the ordinary, rare, unprecedented, unexpected, surprising; strange, odd,freakish, anomalous, peculiar, weird; informal freaky, something else. ANTONYMS normal, usual.


That aside, using try suggests that failure is possible which means it's not exceptional.

-- Kirk 

On 2012-04-23, at 10:09 PM, David M. Lloyd wrote:

> I'm not forcing you to do anything.  I'm saying that exceptions should *not* be used for CAS-style methods, though CAS-style methods could certainly be used to detect cases where an exception should be thrown (using the word "exceptional" to refer to this case BTW is a bit of a semantic land-mine).
> 
> On 04/23/2012 03:06 PM, Kirk Pepperdine wrote:
>> IME, forcing an exception in these cases has been a mistake. You've assumed that if I call putIfAbsent() it's an exception if the put fails. But, putIfAbsent() suggests that the not absent case is expected. It's forcing me to wrap the call with boiler pate when in fact "failure" wasn't an exceptional case in my perfectly reasonable use case.
>> 
>> -- Kirk
>> On 2012-04-23, at 9:54 PM, David M. Lloyd wrote:
>> 
>>> 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
>> 
> 
> 
> -- 
> - DML

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120423/fc6d1c56/attachment-0001.html>


More information about the Concurrency-interest mailing list