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

Aleksey Shipilev aleksey.shipilev at gmail.com
Sun Apr 22 11:18:31 EDT 2012

Hi Doug,

On 04/22/2012 06:56 PM, Doug Lea wrote:
> My main uncomfortableness with the line of attack is that it
> leads to some odd in-between points between FutureTask and
> ForkJoinTask.

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.

If I understand your explanation right, it clearly highlights that
FutureValue functionality better not be done on top of FutureTask,
because that leads to odd consequences with executors. I'm fine with
leaving FutureTask alone: once you have Runnable/Callable you can submit
to threadpool, it's advisable to do so.

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. :(

My observation is that users needing that functionality will end up either:
 a. extending FutureTask and publicizing set()
 b. using single-element BlockingQueue
 c. guard result field with the CountDownLatch
 d. (or even) wait()/notify() for result

All these above are heavier then just FutureValue on top of AQS.


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).

More information about the Concurrency-interest mailing list