[concurrency-interest] The need for a default ForkJoinPool
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
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