seth.m.green at gmail.com
Wed Aug 30 16:37:02 EDT 2006
Sorry. I think I get it now. I wasn't fully understanding the details
of corePoolSize and maximimPoolSize.
Now I see that corePoolSize, is the number of threads that will get
started before handing requests to my queue. Assumeing my queue is
large enough to keep them, the number of threads won't go above
corePoolSize. If my queue gets full, then new threads will get created
until I reach maxPoolSize(). right?
So if I am looking for speed (when I want assign a task, I want it to
run as soon as possible) I should make my queue small and my core and
max large right?
I know I could use a cached executer but I do need to keep some bounds
on my pool.
Seth Green wrote:
> I had no idea the java.util.concurrency library had been backported, and
> I was so fired up to use it. I have some code that uses a
> ThreadPoolExecuter, but it seems that although I have set the
> maximumPoolSize to 50 the pool never grows beyond my corePoolSize.
> Does anyone have a suggestion as to why this would be the case. Is there
> something I should be doing differently?
> I check getMaximimPoolSize() in a number of places and it is always 50,
> but even though I try to assign 50 threads at once, it only ever start 5
> (my corePoolSize).
> Any insight would be greatly appreciated.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest