[concurrency-interest] CountedCompleters

Doug Lea dl at cs.oswego.edu
Wed Apr 11 06:46:42 EDT 2012

On 04/11/12 06:10, Antoine Chambille wrote:
> You have mentioned that counted completers would help with tasks that perform
> IO, or last an unpredicted long time. I think they will also better handle a few
> locking tasks, more efficiently than a managed blocker that is often difficult
> to put in place when the actual lock is hidden.

Yes, thanks. I should mention this in the documentation. (Although
worded in a way that does not encourage people to use locks in tasks,
but mentions CountedCompleters as one way to cope with code that does.)

> That being said when rewriting some of our core algorithms with counted
> completers, I find it difficult to propagate exceptions. It was very fast
> migrating code based on recursive actions, but exceptions thrown in the sub
> tasks would be swallowed (also if that makes you skip the tryComplete() call,
> joining the root task is an infinite wait). When a sub task fails, what is the
> best way to propagate the exception to the parent completer?

When CountedCompleter.compute throws an exception,
and the task is not already marked as completed, it triggers the
internal version of ForkJoinTask.completeExceptionally, which
marks that task as complete with the given exception, and
then does the same for that task's completer, and so on
until hitting a null completer. This should have the effects
you want in most cases, but you can also explicitly call
completeExceptionally in other cases to force this to happen before
return, or internally catch exceptions before returning from
compute if you'd like to handle them differently. If you find
a situation where these options don't suffice, please let me know.


More information about the Concurrency-interest mailing list