[concurrency-interest] Future Get/Done Race Condition

Sam Berlin sberlin at gmail.com
Tue Jan 30 20:36:22 EST 2007

Fair enough.  :)

The CountDownLatch option is probably the best way to go overall, as
it lets the individual FutureTask subclasses control whether or not
done() stalls a get().

I do suggest documentating the asynchronous nature of get/done.  The
current documentation leaves it untouched, which depending on the
reader's viewpoint could mean many different things.  Clarifying that
'done' may not be called prior to 'get' completing may lead more
people to recognize the issue and take care of it before it bites.


On 1/30/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> Sam,
> > Do you think the behavior could be classified as a bug, or subject to
> > fixing/changing in the future?  You're right that it is subjective,
> > but it does seem odd that the documentation suggests that 'done' can
> > perform bookkeeping tasks, yet a get() call can return before the
> > bookkeeping is performed.
> The spec doesn't make it clear what order things happen so there is at least
> room for a clarification. Changing the current behaviour is not an option,
> but perhaps there could be some way to control it. It isn't uncommon for
> "bookkeeping" tasks to occur asynchronously with respect to the main
> behaviour - it all depends on whether that bookkeeping is independent of
> that main behaviour, which in your case it is not. Noone else has raised
> this issue to date so that says something :)
> Cheers,
> David Holmes

More information about the Concurrency-interest mailing list