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

Doug Lea dl at cs.oswego.edu
Sun Apr 22 10:56:09 EDT 2012

On 04/21/12 18:19, √iktor Ҡlang wrote:
>     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.?
> onResult + onException callbacks.

My main uncomfortableness with the line of attack is that it
leads to some odd in-between points between FutureTask and

Backing up: The main difference between them is that a
FutureTask runs a Runnable/Callable that is oblivious
to its surroundings, while the different flavors of
ForkJoinTask have integrated compute methods that can internally
access  all of the task mechanics (including setting results, as
well as extensible completion mechanics in the new CountedCompleter.)

It also just so happens that if you have a ForkJoinTask
rather than a FutureTask or some other Future, we know
how to run it much more efficiently if you submit it to
a ForkJoinPool, as opposed to some other Executor.

There's clearly a place for both the oblivious
and integrated approaches -- We make it pretty easy to
interconvert among them (e.g., in ForkJoinTask.adapt).
But as you keep adding more non-oblivious
methods in FutureTask-like classes, you end up with a
variant of ForkJoinTask that we do NOT know how to
execute as efficiently as real ForkJoinTasks, and I don't
see a path for making them so.


More information about the Concurrency-interest mailing list