[concurrency-interest] Questions about ThreadPoolExecutor

Kwok, Grace (MSCIBARRA) Grace.Kwok at mscibarra.com
Wed Mar 1 18:49:44 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?


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).


I hope it makes sense.
Thank you very much.
Grace






-----Original Message-----
From: Brian Goetz [mailto:brian at quiotix.com] 
Sent: Wednesday, March 01, 2006 2:27 PM
To: Kwok, Grace (MSCIBARRA)
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Questions about ThreadPoolExecutor

>     1)  I need to have the pool customized such when I invokeAll on a 
> Collection of Callables, I also get to specify how many threads I want

> to allocate to run this Collection of Callables.

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.


>     2) The run() method of the runnable (say A) that I submit to the 
> pool might create other runnables (say a and b) which will in terms be

> submitted to the same pool.

This is deadlock-prone unless the _pool_ is unbounded (or you can prove
that the number of tasks submitted will be less than the pool size.)

> However, it looks like
> using SynchronusQueue requires the pool to be unbounded which I don't 
> want.  I want a bounded pool.

SynchronousQueue works best with unbounded pools; with bounded pools, it
will invoke the rejected execution handler to dispose of tasks submitted
in excess of the pool size.

Unless you can bound the task count somehow, you cannot have both of
what you want -- either bound the pool, or don't use tasks that depend
on other tasks.  Otherwise, you're playing Deadlock Roulette.

> Any suggestion on how I can achieve these two criteria using the 1.5 
> concurrency Executor.

Tell us more about the _problem_ you are trying to solve, rather than
the solution you have in mind, and we could probably help further.
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.



More information about the Concurrency-interest mailing list