[concurrency-interest] PooledExecutor vs java.util.concurrent

Jonathan Baxter jbaxter at panscient.com
Wed May 18 05:04:27 EDT 2005

> If you don't care about in-order execution, then you can simply use the
> "caller runs" rejected execution handler.  The result is that the new
> task will be execute in the thread of the submitter, which has the
> effect of throttling that thread's ability to generate more load, giving
> the pool some time to catch up.

This doesn't work for the use case in my original post: two separate thread 
pools with different resource usage characteristics. Eg, threads in pool A 
run a low-cpu task that spends most of its time waiting on the network - say 
100 threads. Threads in pool B run a high-cpu task, and is deliberately set 
small so as not to overwhelm the jvm - say 5 threads. If the threads in pool 
A implement "caller runs" as they hand-off to thread pool B, you can end up 
starving the rest of the threads in pool A: eg 80 threads in A executing 
their work, 20 executing thread pool B work as "caller runs", and another 5 
in pool B executing their work. Instead of bounding the resources consumed by 
pool B you have 5 times as many threads executing B work as you tuned for. 

More abstractly, it seems to me that "caller runs" isn't necessarily the right 
thing to do if there is an "impedance mismatch" between the two worker pools. 
Whereas if thread pool B blocks on handoff, you might end up with 20 pool A 
threads waiting to submit work to pool B, but that is preferable to 
potentially killing the jvm by overloading on pool B work.  

More information about the Concurrency-interest mailing list