[concurrency-interest] The need for a default ForkJoinPool

David Holmes davidcholmes at aapt.net.au
Mon Aug 16 18:53:10 EDT 2010


If threads explicitly attached and detached from libraries then a
Threadlocal might be appropriate, but in general I think it is a very bad
mechanism because the right pool is a function of the library not of the
thread using it!

I think libraries must allow for a default pool while also supporting an
explicit pool.

I think what differentiates this case from other global "thread pools" is
that the scope of usage is potentially much broader and that the pool will
not necessarily grow as demand increases.

I also think, and perhaps it is just my misunderstanding here, that having
multiple simultaneous users of a FJPool is going to be counter-productive. I
can get good speedup doing a parallel sort of one huge array, but if I try
to sort two huge arrays at the same time then I'm just stepping on my own
toes. If a pool processes one task then all stealing aids that task; with
multiple tasks you really have no idea how long each one will take.

Which would perform better: one pool of N thread processing 2 arrays, or 2
pools of N/2 threads processing 1 array each?

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Gregg
> Wonderly
> Sent: Tuesday, 17 August 2010 3:32 AM
> To: Kasper Nielsen
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] The need for a default ForkJoinPool
>
>
> It seems like there should be a default to use which falls out of
> the context of
> the executing thread too.  Using a ThreadLocal, as here, helps to
> keep previous
> 'knowledge" of the pool intact for subsequent uses without all
> the burden of
> maintaining all the context necessary for every point of
> execution to know what
> the previous did.
>
> Gregg Wonderly
>
> Kasper Nielsen wrote:
> > Im just throwing this into the discussion, it might be really bad idea.
> > Haven't thought it through completely.
> >
> > This is primarily thought to be a way for applications servers such as
> > Tomcat/Weblogic/Websphere to have better control over which threadpools
> > should be used in case we decide on a single system-wide threadpool.
> >
> > Again i really want to just expose a simple api such as
> > parallelSort(int[] array) to users. Now, for example, when I'm using
> > Weblogic i often use its build-in functionality for prioritizing
> > requests. So request from user A uses high priority Threadpool 1, and
> > requests from user B uses low priority Threadpool 2. If both users
> > requires calls to parallelSort they effectively have the same priority
> > because they both use the single shared threadpool.
> >
> > Something like this would allow complete control to containers.
> >
> > public class ForkJoins {
> >
> >     private final static ThreadLocal<SoftReference<ForkJoinPool>>
> > FJP_THREAD_DEFAULT = new ThreadLocal<SoftReference<ForkJoinPool>>();
> >     private final static ForkJoinPool DEFAULT = new ForkJoinPool();//
> > not lazy for simplicity issues
> >
> >     public static ForkJoinPool get() {
> >         SoftReference<ForkJoinPool> sr = FJP_THREAD_DEFAULT.get();
> >         if (sr != null) {
> >             ForkJoinPool fjp = sr.get();
> >             return fjp != null ? fjp : DEFAULT;
> >         }
> >         return DEFAULT;
> >     }
> >
> >     public static void setThreadDefault(ForkJoinPool fjp) {
> >         //Security checks
> >         FJP_THREAD_DEFAULT.set(new SoftReference<ForkJoinPool>(fjp));
> >     }
> > }
> >
> > Cheers
> >   Kasper
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
>
> _______________________________________________
> 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