[concurrency-interest] The need for a default ForkJoinPool

David Holmes davidcholmes at aapt.net.au
Sun Aug 15 20:04:46 EDT 2010


Hi Doug,

As a slight refinement on the default pool, I would suggest adding a way to
set the default pool. That way the "default default" can prohibit shutdown,
while a "custom default" would allow user-defined policies, including
allowing shutdown. Being able to set the default via a system property, in
addition to an explicit setXXX method, would provide more flexibility.

   volatile ForkJoinPool fjp;

   public void setDefaultPool(ForkJoinPool p) {
     fjp = p;
   }
   public static ForkJoinPool getDefaultPool() {
     ForkJoinPool def = fjp;
     if (def != null) return def;

     String fjpc = (String) System.getProperty("xxxx.ForkJoinPool.default");
     if (fjpc != null) {
        try {
            // spi-style reflective construction
            ...
            fjp = def;
            return def;
         } catch (...) { ...}
     }
     def = new ForkJoinPool() {
        public void shutdown() {
           // ignore or throw
        }
         ...
     };
     return def;
   }

Though this implies the custom default has its own means of determining the
desirable construction parameters.

Cheers,
David

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea
> Sent: Monday, 16 August 2010 8:30 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] The need for a default ForkJoinPool
>
>
> On 08/15/10 07:38, Kasper Nielsen 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.
> >
>
> 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
> parameters.
>
> 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.
>
> -Doug
> _______________________________________________
> 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