[concurrency-interest] The need for a default ForkJoinPool

David Holmes davidcholmes at aapt.net.au
Sun Aug 15 19:50:18 EDT 2010


Kasper Nielsen writes:
> 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.

I think as a library provider you must do the latter. You can't assume that
you know how pools should be created or used, so all you can do is have the
user supply you with one. I understand this is somewhat awkward as you don't
necessarily want this on every method that is an entry-point to your
library; nor is it usual to have an explicit "init" method for a library,
that could be used to set this. But you need some technique for the library
user to "configure" your library with regard to the pool to be used. It may
also be that different parts of the application may want to use your library
with different underlying pools - again indicating the user must supply the
pool to be used somehow.

I do agree that there should be a default pool easily accessible to the
user - and created only on demand - but other libraries should only use that
default as a fall-back for when the user does not provide one, or uses the
library in a way that says "use the default pool for this" - the user has to
have the control here.

Cheers,
David Holmes

> 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.
>
> Cheers
>    Kasper
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list