[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.

Sam

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