[concurrency-interest] The need for a default ForkJoinPool

Kasper Nielsen kasper at kav.dk
Mon Aug 16 05:33:56 EDT 2010

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));


More information about the Concurrency-interest mailing list