[concurrency-interest] Future Get/Done Race Condition

Sam Berlin sberlin at gmail.com
Wed Jan 31 14:45:53 EST 2007

As we investigated the CountDownLatch, we noticed that that allowing
get() to complete prior to done() is a very useful feature.  Many
done() implementations will want to query get() to perform the
bookkeeping based on the result.  If get() required done() to
complete, then there would be a deadlock whenever get() was called
within done().  So, the current behavior does seem to be the best
choice overall, though documenting it would be even better.


On 1/31/07, Martin Buchholz <Martin.Buchholz at sun.com> wrote:
> Whether done() should complete before releasing threads blocked
> in get() is tricky.  If we were to start from scratch, I would
> prefer to have the more predictable serialized behavior where
> returning from get() guarantees that done() has completed.
> But compatibility trumps possibly better design here.
> We have a very similar issue with ThreadPoolExecutor.terminated().
> There the historical behavior is the opposite.
> Threads returning from ThreadPoolExecutor.awaitTermination()
> have a guarantee that terminated() has completed,
> and we have been careful to preserve that behavior in
> in-progress changes to ThreadPoolExecutor.
> In neither case do we currently document the behavior.
> I think that's a bug.
> I filed Sun bug
> 6519887: Document whether "done" methods execute before waiters are released
> Martin
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list