[concurrency-interest] The need for a default ForkJoinPool

Kasper Nielsen kasper at kav.dk
Sun Aug 15 07:38:17 EDT 2010


Having used the FJ classes for a couple of libraries. The one thing that 
is really annoying me is the fact that there are no default ForkJoinPool 
I can use.

If you are designing a library a.la. a parallel ju.Arrays library that 
uses the FJ classes. You have two choices: either you can create a new 
ForkJoinPool and use it internally in your library. Or you can ask the 
user to provide one, something like sort(ForkJoinPool pool, int[] 
array). And I really don't like any of the alternatives.

The first one because I see more and more projects that uses 20-30 or 
even more different libraries. If they all need to create a ForkJoinPool 
internally it is going to get very messy with too many threads 
especially for processors with many cores. And it there is a problem now 
it is only going to get worse in the future.

The second one because it is just annoying for users that pass 
ForkJoinPools around all the time. Normal users do not want to get 
bugged down by details like this.

So i suggest a single static method on ForkJoinPool
ForkJoinPool defaultForkJoinPool();

Which returns a lazy initialized default ForkJoinPool that can be used 
across of different libraries/code. Maybe coupled with a security 
manager check before returning the ForkJoinPool

I also think it will make people more willing to use it in their 
libraries. Forcing people to create availableProcessors() threads, at 
least makes me think if I can solve the problem in any other way.

For those 5 % of users that needs something advanced they can still 
create their own ForkJoinPool.

Its probably not an optimal solution, but I think the alternative of not 
providing a default pool is much worse.


More information about the Concurrency-interest mailing list