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

Doug Lea dl at cs.oswego.edu
Sun Apr 22 15:49:39 EDT 2012


On 04/22/12 11:18, Aleksey Shipilev wrote:
> Sorry, but I fail to see the connection between FutureTask/ForkJoinTask
> and proposed FutureValue. In my perspective you should not be able to
> submit FutureValue anywhere, this is just the efficient shortcut for
> asynchronously-settable value.

Yes. I was commenting on adding operations like onResult, etc
that invite usages requiring them be submittable to Executors.

> However, there are cases when I need to communicate single value between
> two threads, with one thread blocked for the result. This is the case
> where FutureValue comes handy. The cases like these are not as rare as
> one might expect. :(
>

Yes, I agree that this is (only) the functionality to target.

> P.S. I'm not allowed to look into Guava source code, but I will bet
> their SettableFuture is done directly on AQS (it's the only sane option
> at hand).
>

(It is.)

-Doug


More information about the Concurrency-interest mailing list