JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post

[Doug Lea]

On 10/05/11 03:53, Kasper Nielsen wrote:
> On 05-10-2011 05:08, Andrew Thompson wrote:
>> So is there any convergence between these ideas? Should we be thinking about
>> adding a default ForkJoinPool to the platform, or should we be thinking about
>> adding a default ExecutorService to the platform,
>
> There was a discussion about this on the jsr-166 mailing list last year:
>
> http://cs.oswego.edu/pipermail/concurrency-interest/2010-August/007334.html

There are two main (entangled) issues here:

1. How do you avoid requiring every method that might entail
parallelism to include a parameter indicating the Executor to use,
but still allow overrides?

2. How do you deal with possibly varying scheduling policies
of different Executors? For example, while the use of
work-stealing vs centralized queue in FJ is semantically
neutral, its default locally-LIFO policy is not -- there
are non-ForkJoin-like usages that only work well if the
policy is overridden to be locally-FIFO (which is intrinsically
a global set-once-in-constructor policy).

Here are a few thoughts on resolution.

1. An Executor could be associated with each ThreadGroup,
as a sort of InheritableThreadGroupLocal:
  * by default in the initial ThreadGroup it is some common
    global Executor that can be set by a Property
  * A new ThreadGroup constructor allows creation of one
    used by all threads in the group
  * A new ThreadGroup created without an override uses
   the one in used by the thread calling the new ThreadGroup
   constructor. This might also be overridable via some Property

So, if you'd like to use an alternative common executor,
you'd need to either create a new ThreadGroup or change some
Property. This is not perfectly flexible, but probably
flexible enough to still be better than the alternative
of adding Executor parameters to the many classes/methods
that will surely be created in the future as more and more
functionality entails parallelism. Plus all the cases where
you cannot do this because you'd like change existing methods
that do not have any such parameters.

2. Some metadata could be associated with the above executors
that individual classes/methods could use to decide if they
need to waste the time/space creating a different kind of
executor for their service. These attributes would need to
simply structured and trivial to check, since you do not want
to create a sequential bottleneck just deciding which parallel
facility to use.

-Doug