[concurrency-interest] The need for a default ForkJoinPool
djg at cs.washington.edu
Sun Aug 15 23:49:03 EDT 2010
>From a beginner's pedagogy perspective, having a default pool is
tempting and none of the downsides seem to apply. It would save a
couple lines of boilerplate, which is always nice.
But it doesn't seem like such a big deal. I don't hink I told my
students what this "pool" was, just that it was necessary for
initializing the library and then calling into it. Because some
libraries /do/ have a mandatory "init" function, living with the need
to create a pool doesn't seem any worse.
On Sun, Aug 15, 2010 at 3:30 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 08/15/10 07:38, Kasper Nielsen wrote:
>> Having used the FJ classes for a couple of libraries. The one thing that
>> really annoying me is the fact that there are no default ForkJoinPool I
>> can use.
> I think this will become a common concern. I'm not sure what
> the best solution is though. In most ways, it makes sense
> to have exactly one pool per program constructed with default
> target parallelism (i.e., equal to #CPUs/cores). If you have
> more than one, then they will eat up unnecessary resources
> and will contend with each other. It also can make sense to
> to occasionally use others with lower parallelism or different
> On the other hand, some methods (like shutdown) on a single global
> pool could not be made accessible.
> Also, as implied by Tim, having a single global pool invites
> surprise and unhappiness when unknown other parts of a system
> are abusing it -- for example running tasks that never terminate
> or lock themselves up.
> It might be reasonable to compromise along the lines you suggest
> -- to have a default one (that we would need to support by somehow
> disabling shutdown etc), so that people at least knowingly expose
> themselves to the risks.
> Other suggestions welcome.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest