[concurrency-interest] Parameterized CountedCompleters

Doug Lea dl at cs.oswego.edu
Mon Aug 20 10:49:09 EDT 2012

On 08/20/12 07:35, Mohan Radhakrishnan wrote:
> Hi,
> I have some questions from the perspective of a programmer using this. for
> general development. ...
> Applicability
> # More well-behaved than RecursiveAction when tasks block ( Is there more
> explanation for why they are well behaved ? )

Like other completion-based design patterns (google will find some
descriptions), the main problem they avoid in Future-based programming
is that if some task1 is blocked in IO, and some other task2
is joining task1 then task2 is also blocked. Eventually this can
tie up a lot of tasks/threads. The solution amounts to having task2 ask
task1 to do whatever task2 would have done after the join --
task2 is then no longer involved. CountedCompleters add one more
bit of control versus other completion  frameworks:
you can ask that a number of other tasks complete, not just
one, before performing the completion action. This enables recursive,
tree-style and other uses.

>          public final void compute() {
>              MasterSocketReceiver msr = new MasterSocketReceiver( new
> MasterCompleter());
>              msr.fork();
>              SlaveSocketReceiver ssr = new SlaveSocketReceiver( new Completer() );
>              ssr.tryComplete();
>              System.out.println( "MasterSocketReceiver" );
>          }
>      }

I don't offhand understand your intent here, but calling tryComplete
on some other task is very rarely appropriate.


More information about the Concurrency-interest mailing list