[concurrency-interest] Help, how to design a pool of executors

Joe Bowbeer joe.bowbeer at gmail.com
Fri Nov 4 02:36:24 EST 2005

I believe the cancellation mechanism you desire can be implemented by
hooking the done() method of FutureTask.

For some executor service,

ExecutorService service = Executors.newFixedThreadPool(n);

You can create and execute your tasks roughly as follows:

Runnable task = new FutureTask(callable) {
  protected void done() {
    try {
      System.out.println("Answer is " + get());
      // succeeded - shutdown service
    } catch (Exception ex) { }


Note that in our terminology, a ThreadPool executor maintains a "pool"
of threads and a queue of tasks.

On 11/3/05, Andrej Navodnik <andrejnavodnik at yahoo.com> wrote:
> Hello all,
> I would kindly ask someone for a gentle hand to guide
> me through the
> problems related to the concurrent programming.
> My problem is the following. I'd like to design a
> special structure/pool of
> executors which gives a priority to the task that
> testing element satisfies
> a special intermediate condition. If an algorithm
> could verify that the
> testing element is appropriate for further use then
> the task that has
> found this element is allowed to cancel all other
> tasks in pool and calculate
> the final result based on this "optimal element".
> Let's say that I have a set of elements from which I
> want to find  an optimal
> element. During testing whether an element is
> appropriate or not an element must
> satisfy some kind of an intermediate condition. If an
> intermediate condition is
> not satisfied then the pool select another element for
> testing. If this
> intermediate condition is satisfied then the task that
> has found this element:
>   - is allowed to cancel all other tasks in the pool;
>   - is allowed to disable that the pool could to
> accept new elements for testing;
>   - is the only one that is allowed to continue and
> calculate the final result.
> Structure should either return null (there are no
> elements that could satisfy
> an intermediate condition) or final result based on
> input "optimal element".
> The behavior of the tasks in the pool could be
> explained with the following
> picture:
> 0----5------x
>  1-----7----x
>   2---6-----x
>    3-----9-!-------------->
>     4---8---x
> Legend:
> 0, 1, 2, 3, 4: ... finished tasks/elements which could
> not satisfy
>                    intermediate condition;
> 5, 7, 6, 8: ...... canceled tasks by task testing
> element number 9;
> 9: ............... task that has found that an element
> that satisfies intermediate
>                    condition, has canceled all other
> currently running tasks
>                    in the pool and is allowed to
> calculate the final result;
> !: ............... time when the task has found out
> that the element number 9
>                    satisfies an intermediate
> condition; from that time on the task
>                    with element number 9 is the only
> one executing in the pool;
> Is it wise to design such kind of structure? I'm
> prepared to do some homework
> but I don't know where to start (which objects to put
> together). Is it possible
> that the costs using this kind of structure could be
> higher than the benefits?
> I'm aware of the examples in class
> ExecutorCompletionService but are not
> behaving the way I want.
> Best regards,
> Andrei

More information about the Concurrency-interest mailing list