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

√iktor Ҡlang viktor.klang at gmail.com
Mon Apr 23 16:33:43 EDT 2012


On Mon, Apr 23, 2012 at 10:09 PM, David M. Lloyd <david.lloyd at redhat.com>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).


Absolutely, this reflects my experience and also is how SIP-14
(scala.concurrent.Future) is designed:

complete == throw if future already completed
tryComplete == return whether this call completed the future or not

Cheers,
√


>
>
> 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<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/<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<Concurrency-interest at cs.oswego.edu>
>>>>>>>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ______________________________**_________________
>>>>>>>> Concurrency-interest mailing list
>>>>>>>> Concurrency-interest at cs.**oswego.edu<Concurrency-interest at cs.oswego.edu>
>>>>>>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> - DML
>>>>>>> ______________________________**_________________
>>>>>>> Concurrency-interest mailing list
>>>>>>> Concurrency-interest at cs.**oswego.edu<Concurrency-interest at cs.oswego.edu>
>>>>>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> - DML
>>>>>
>>>>
>>>>
>>>
>>> --
>>> - DML
>>>
>>
>>
>
> --
> - DML
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120423/5415f0e7/attachment.html>


More information about the Concurrency-interest mailing list