[concurrency-interest] ForkJoinPool.managedBlock() not spawning new thread

Doug Lea dl at cs.oswego.edu
Thu Jul 19 13:52:49 EDT 2012

On 07/19/12 11:41, Alex Lam S.L. wrote:
> I am trying to get my application to use ForkJoinPool. Specifically, I
> want it to automatically occupy all 8 CPUs even when one of the thread
> is blocked by BlockingQueue.take() - below is an implementation based
> on what I can understand from the javadocs:

> Now on my 8-core machine, I can see from JConsole that FJ pool have 8
> threads, with one of them consistently blocking on queue.take(), thus
> only leaving 7 CPUs busy.
> Is this behaviour intentional? If so, what am I doing wrong here?

It is intentional that the ManagedBlocker API not continuously
spawn threads -- this leads to positive feedback loops that
can lead to unbounded resource usage. This also means that
it might not spawn a thread when you might think it should.

See discussions about CountedCompleters on this list for a
generally more well-behaved approach to tasks that may block.

Additionally, or alternatively, you can pad the pool size to a
value that better estimates actual CPU-intensive load. In general,
work-stealing has the property that as you use more threads than
CPU cores, performance only slowly degrades due to more context switching.
So, if you can make estimates are not grossly wrong, this may
lead to better average utilization and throughput.


More information about the Concurrency-interest mailing list