MaximumPoolSize not used with unbounded queues

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

MaximumPoolSize not used with unbounded queues

david gonneau
Hi,

I am using a threadPoolExecutor with a PriorityBlockingQueue (not bounded).

I made the choice of an unbouded queue to be able to resize the queue dynamically using the setMaxCapacity() without having to kill my executor or my queue.

I don't see why the MaximumPoolSize wouldn't be used in that case.

If I set 2 thread in the corePool and 5 as maximumPool, only my 2 threads of the core will be spawned. Then for further tasks coming, as long as the two first threads are busy, the queue will be used to store the incoming tasks. Without even trying to spawn new threads as specified on the maximumPoolSize..

Why such a limit ?

Is there any way to bypass this ? Is there a valid reason of not using temporary threads with an unlimited queue ???

Thanks for ur inputs :)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: MaximumPoolSize not used with unboundedqueues

David Holmes-3
David,
 
A similar issue was discussed not that long ago, so please also see the archives.
 
Basically the design for ThreadPoolExecutor is to handle an incoming task as follows:
 
1. create (or use if prestarted) core thread if less than coreMax; else
2. offer to queue; else (if queue is bounded and full)
3. create pool thread if less than max; else
4. invoke RejectedExecutionHandler
 
The basic design philosophy is that the core exists to handle the normal workload. The queue exists to buffer tasks that come in quicker than the pool can handle. You bound the queue if you need to ensure the outstanding tasks don't grow without limit and allow the pool to grow beyond core to try and catch up with the (hopefully temporary) overload. You typically set a timeout so the extra threads die out when things are quiet again.
 
If you have an unbounded queue then steps 3 and 4 never come into play. If you have an unbounded queue but wanted to expand the pool size too, then how would you have that decision be made? Would you add to the queue and add a new thread? That would be a possibility. However this is no way to customize this behaviour in ThreadPoolExecutor.
 
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of david gonneau
Sent: Thursday, 30 March 2006 11:19 PM
To: [hidden email]
Subject: [concurrency-interest] MaximumPoolSize not used with unboundedqueues

Hi,

I am using a threadPoolExecutor with a PriorityBlockingQueue (not bounded).

I made the choice of an unbouded queue to be able to resize the queue dynamically using the setMaxCapacity() without having to kill my executor or my queue.

I don't see why the MaximumPoolSize wouldn't be used in that case.

If I set 2 thread in the corePool and 5 as maximumPool, only my 2 threads of the core will be spawned. Then for further tasks coming, as long as the two first threads are busy, the queue will be used to store the incoming tasks. Without even trying to spawn new threads as specified on the maximumPoolSize..

Why such a limit ?

Is there any way to bypass this ? Is there a valid reason of not using temporary threads with an unlimited queue ???

Thanks for ur inputs :)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest