[concurrency-interest] The need for a default ForkJoinPool

Tim Peierls tim at peierls.net
Sun Aug 15 08:04:40 EDT 2010


I disagree. There's a potential for a "tragedy of the commons" lurking in
the provision of a default thread pool. I think the problem is better solved
with dependency injection.

--tim

On Aug 15, 2010 7:41 AM, "Kasper Nielsen" <kasper at kav.dk> wrote:

Hi,

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.

Cheers
 Kasper
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100815/3f7b0f19/attachment.html>


More information about the Concurrency-interest mailing list