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

David M. Lloyd david.lloyd at redhat.com
Mon Apr 23 17:37:43 EDT 2012


Indeed this underlines my point that "exceptional" is not used solely to 
mean "throws an exception".  Instead it's just "uncommon".  It is pretty 
normal, in my experience, to see and write CAS-oriented code which is 
optimized for the common case.  Returning true in this case is the 
common case, and returning false is the "exceptional" or uncommon case 
(but with no Java exception objects in sight).

On 04/23/2012 03:30 PM, Kirk Pepperdine wrote:
> ahhh, my misunderstanding and my appologies.
>
> Using the word exceptional shouldn't be a semantic land-mine. It has a
> very clear definition.
>
> exceptionaladjective1 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
>>>>>>>>>> <mailto:Concurrency-interest at cs.oswego.edu>
>>>>>>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Concurrency-interest mailing list
>>>>>>>>> Concurrency-interest at cs.oswego.edu
>>>>>>>>> <mailto: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
>>>>>>>> <mailto:Concurrency-interest at cs.oswego.edu>
>>>>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> - DML
>>>>>
>>>>
>>>>
>>>> --
>>>> - DML
>>>
>>
>>
>> --
>> - DML
>


-- 
- DML


More information about the Concurrency-interest mailing list