[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)
tim at peierls.net
Sat Apr 21 17:56:47 EDT 2012
Guava's SettableFuture  provides this behavior, or comes very close. I'd
be interesting in hearing from people who are dissatisfied with the current
j.u.c to what extent, if any, com.google.common.util.concurrent 
addresses those dissatisfactions.
On Sat, Apr 21, 2012 at 5:25 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> 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
>> > 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest