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

Aleksey Shipilev aleksey.shipilev at gmail.com
Sat Apr 21 17:06:16 EDT 2012

On 04/22/2012 12:33 AM, Joe Bowbeer 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).

Yes, I will support this thinking.

Returning boolean definitely helps with two threads racing to set the
result. What should be the behavior when one thread is setting the
completed result, and other sets the exception? Making these two cases
distinct raises a weird corollary for two consecutive get()-s: first can
return the proper result, and then second one throw the
ExecutionException. I think this somewhat isolated by FutureTask now
requiring proper Runnable/Callable to be executed, but we need to
recheck if that race is still viable with manual set()/setException().

> Are there any other Future enhancements that you think are sorely needed
> in j.u.c.?

I think that's the one. Otherwise I am very happy with j.u.c.


More information about the Concurrency-interest mailing list