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

Aleksey Shipilev aleksey.shipilev at gmail.com
Sat Apr 21 15:08:10 EDT 2012

On 04/21/2012 06:51 PM, Doug Lea wrote:
> Although it would seem that if you could add SettableFuture, you
> might as well just take/adapt the updated FutureTask class instead?
> Even if you have to cripple it a bit by using AtomicXFieldUpdaters
> instead of direct CAS calls, it is probably a better option.

In fact, this was the starting point of this whole trouble.

Some library guys have indeed copied FutureTask into their project and
hacked it to allow public set(). It is 1:1 comparable with JDK-ish
version, but it will never get the proper fix from JDK. So they now are
persuaded to extend FutureTask directly, to pick up whatever
fixes/changes are there in JDK.

> If not, your workaround seems OK though.

Thanks for reviewing it. The beauty of this workaround is that once the
fix hits the JDK, maintainers can remove synchronized {}, and that
single change transforms this class to just one single adapter.

> (BTW, one moral of that CR is that whenever you don't explicitly
> disallow an unintended usage, it will eventually  end up as a
> bug report :-)

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? :)


More information about the Concurrency-interest mailing list