[concurrency-interest] Questions about ThreadPoolExecutor

Brian Goetz brian at quiotix.com
Wed Mar 1 19:07:13 EST 2006


> "You can create a custom Executor for each batch of Callables.  You will
> probably want to use some other bounding mechanism to ensure that
> aggregate number of threads created by such executors doesn't exceed
> some threshold."
> 
> If I am to create an Executor for each batch of Callables, the threads
> from Executor 1 could not be reused by threads from Executor 2, is that
> correct?  Is this optimal?  Is this like a pool of Executors?

You are correct.  Optimal?  That depends on your requirements.

> Basically, I am facing a customized thread pool class that is written
> pre 1.5 and I want to replace that with the Executor.  The customized
> thread pool class allows specifying the number of threads to run for
> each batch because each batch is big and we don't want one thread
> created per task of each batch.  If we create one thread per
> task/Callable of each batch, one batch would take away all the thread
> resources and won't allow other batches to start running.  Currently, if
> thread count is exceeding a threshold, it would use the current thread
> to run the tasks in the batch single-threadedly and use other threads in
> pool when they become available. (But the "single-threadedly" would only
> work for synchronous call and not asynchronous call).

If each batch is big, then specifying a separate executor for each batch 
is not going to be a big source of inefficiency.  You will still want to 
allocate threads to executors in some sensible way, like using a 
Semaphore.

Basic idea:
   N = total number of threads available for execution of all batches

   Semaphore sem = new Semaphore(s);

   Collection<Future> executeBatchCollection<Task> tasks, int nThreads) {
     sem.aquire(nThreads);
     try {
         ExecutorService exec = Executors.newFixedThreadpool(nThreads);
         Collection<Future> result = exec.invokeAll(tasks);
     }
     finally {
       exec.shutdownNow();
       sem.release(nThreads);
     }
   }





More information about the Concurrency-interest mailing list