[concurrency-interest] Questions about ThreadPoolExecutor

Joe Bowbeer joe.bowbeer at gmail.com
Thu Mar 2 14:43:47 EST 2006

On 3/2/06, Kwok, Grace (MSCIBARRA) <Grace.Kwok at mscibarra.com> wrote:
> >"In your case, you'd write a BatchExecutor that submitted its tasks to
> a master executor. "
> Since my original problem is to be
> 1) - able to specify the number of threads to run each batch of tasks.
> (i.e. I have a batch of 100 tasks; I only want to allocate 6 threads to
> be running them even if the pool has more than 6 threads available.  The
> reasons are one, I don't want one batch to take away all the thread
> resources and two, if the tasks are big stress to the db, I simply want
> the control to be able to specify less threads to run them.)
> 2) - bound the size of the pool
> 3) - avoid task deadlocks
> 4) - would need something like invokeAll(..) in ExecutorService to wait
> and get my result back.
> 5) - nice to be able to reuse threads in pool instead of creating an
> Executor for each batch since some batch might be small, some are large.
> In your suggestion of this BatchExecutor, in esssense, there is really
> one Executor, I am not so clear on how I would achieve 1 and 4?  Would
> my BatchExecutor has to be wise in figuring out the pace of dispatching
> to the master executor so to satisfy X number of threads running the
> batch of tasks?

I wasn't trying to promote BatchExecutor, but to provide an example of
how one executor could proxy for a second.  The example I provided was
a SerialExecutor, that is, a batch of one.  Whereas in your case you'd
need an executor that dealt with larger batches.

If I understand your scenario correctly, the cleanest approach I can
think of would be to run each batch in a dedicated executor configured
as a cachedThreadPool with a maximumPoolSize appropriate for each
batch, a CallerRuns rejectedExecutionHandler, and a short

The part of your scenario that I'm sure I don't understand is the
interdependency between tasks within and between batches.


More information about the Concurrency-interest mailing list