[concurrency-interest] Future Get/Done Race Condition
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
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest