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

Aleksey Shipilev aleksey.shipilev at gmail.com
Mon Apr 23 16:50:34 EDT 2012

I'm good with having trySet() method returning boolean, and set()
throwing the exception. One could certainly argue whether returning
false is considered exceptional, and there are cases when the opposite
is true. So, instead of imposing these artificial constraints based on
our momentary understanding of use cases, it's better to support both
and let user decide. Even though I have the premonition about adding
new checked exceptions to JDK code.


2012/4/24 √iktor Ҡlang <viktor.klang at gmail.com>:
> 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


More information about the Concurrency-interest mailing list