[concurrency-interest] new task coordination operations

Doug Lea dl@cs.oswego.edu
Mon, 15 Dec 2003 11:56:14 -0500

People who thought we (the JSR166 expert group) were too cowardly over
the past year in not taking a stance on providing APIs for managing
sets of asynch tasks can thank those J2EE JSR proposers for goading us
into yet further last-minute action. We now realize that without
these, we would have failed to provide a reasonable basis for this and
other other layered APIs.

We were still slightly indecisive about which of the paths to
take here, so we decided to support two styles.

The more general of these is the CompletionService interface and
ExecutorCompletionService class. This is a lightweight class that can
be attached to any Executor to manage completion queues, and
can be used to coordinate lots of common asynch task problems.

The second is to new methods invokeAny and invokeAll in
ExecutorService. These take lists of tasks, execute them all, and then
wait for at least one (invokeAny) or all (invokeAll) to complete.
While these can be implemented easily using a CompletionService, they
are common enough to expose separately, and also admit special-purpose
solutions that might be a bit more efficient in some ExecutorServices
than you could obtain yourself.

We are still in the midst of debating a few minor API issues surrounding
these, but the current versions are now out in the usual place:
And feedback will be most welcome.

Note that we are still too cowardly to establish particular callback
APIs though. Instead, as always, we support subclass hooks in concrete
Executor and Future classes so you can define them yourself.