[concurrency-interest] The need for a default ForkJoinPool

Kasper Nielsen kasper at kav.dk
Tue Aug 17 16:51:07 EDT 2010

On 17/08/10 00.53, David Holmes wrote:
> If threads explicitly attached and detached from libraries then a
> Threadlocal might be appropriate, but in general I think it is a very bad
> mechanism because the right pool is a function of the library not of the
> thread using it!
I disagree, the right pool depends on the context you use the library in 
not on the library it self. At least when in comes to ForkJoinPools 
because all tasks are supposed to be CPU bound. So if you processing 
your request in a thread with a high priority, you also want to be able 
to sort you big array with a high priority.
Likewise while running with a thread with a low priority you don't
want to block high priority requests because your library uses the same 
pool for all your requests.

Thats why I think something like
would be appropiate

> I think what differentiates this case from other global "thread pools" is
> that the scope of usage is potentially much broader and that the pool will
> not necessarily grow as demand increases.
> I also think, and perhaps it is just my misunderstanding here, that having
> multiple simultaneous users of a FJPool is going to be counter-productive. I
> can get good speedup doing a parallel sort of one huge array, but if I try
> to sort two huge arrays at the same time then I'm just stepping on my own
> toes. If a pool processes one task then all stealing aids that task; with
> multiple tasks you really have no idea how long each one will take.

Normally you will just have a single FJPool in your system. Ideally a 
single FJPool with NumberOfProccessors threads should be adequate for 
most programs. Job submissions are queued up FIFO wise internally.

> Which would perform better: one pool of N thread processing 2 arrays, or 2
> pools of N/2 threads processing 1 array each?
The first one. Say you have 2 pools and the first pool sorts the array 
real quick because it is easier to sort (smaller/ semisorted/...). The 
second pool has a more work to do while sorting its array. But because 
you are using two pool the threads from the first pool are unable to 
steal tasks from the second pool and you are basically only using half 
of your CPUS/cores.


More information about the Concurrency-interest mailing list