[concurrency-interest] Sharing threads across executors

Joe Bowbeer joe.bowbeer at gmail.com
Sun Mar 14 00:25:51 EST 2010


The mechanism for sharing a single threadpool across multiple executors is
delegation, as in your implemented solution.

Since a ScheduledThreadPoolExecutor is a type of ThreadPoolExecutor, why not
make the STPE the root of your executor tree?  In which case, tasks that
need immediate execution would be submitted via execute(), and only the
delayed tasks would be be submitted via one of the schedule() methods.

If you want the idle STPE threads to die off, can you use setKeepAliveTime
and allowCoreThreadTimeOut?  Even though a STPE is constructed with a fixed
core size, I *think* these methods will still behave in their specified way.

Joe

On Sat, Mar 13, 2010 at 5:09 PM, Dibyendu Majumdar wrote:

> Hi,
>
> I am building a system where there are many modules that need to run
> background tasks. The requirement is that the tasks execute without blocking
> as otherwise performance will be impacted. On the other hand I want to avoid
> having too many threads sitting idle.
>
> I may have misunderstood, but it seems to me that there is no mechanism for
> sharing a single threadpool across multiple executors. Conceptually, I'd
> like each executor to have its task queue, but share the thread pool with
> other executors, so that the pool of threads is optimised.
>
> I also need the ability to run certain tasks at scheduled intervals.
>
> For now, the solution I have implemented is as follows:
>
> I use a single ThreadPoolExecutor to run all tasks.
> I use a separate ScheduledThreadPoolExecutor to manage scheduled tasks.
> This executor does not run the tasks, instead it submits the tasks when
> ready to the first ThreadPoolExecutor. This pool has only 1 thread
> allocated.
>
> With this solution I am close to what I wanted, but I cannot avoid having
> one thread (ScheduledThreadPoolExecutor) being idle most of the time.
>
> Is there a better way of achieving this?
> Why is the scheduling function tied to the threadpool management? It would
> seem to me that these are separate concerns.
>
> Thanks very much in advance for your help and advice.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100313/0279ce7c/attachment.html>


More information about the Concurrency-interest mailing list