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

Joe Bowbeer joe.bowbeer at gmail.com
Sat Apr 21 17:25:29 EDT 2012


On Sat, Apr 21, 2012 at 2:06 PM, Aleksey Shipilev wrote:

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


My assumption is that the FutureValue can only complete once, whether by
cancel(), set(v), or setException(e).

Once complete, isDone returns true, and set(v) and setException(e) do
nothing but return false.

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120421/642941f5/attachment.html>


More information about the Concurrency-interest mailing list