[concurrency-interest] The need for a default ForkJoinPool

David Holmes davidcholmes at aapt.net.au
Tue Aug 17 18:15:35 EDT 2010


Kasper Nielsen writes:
> On 17/08/10 00.53, David Holmes wrote:
> > 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 disagree, the right pool depends on the context you use the library in
> not on the library it self.

Not if the library is trying to encapsulate the pool the way some libs
currently encapsulate executors. It does indeed depend on context, and my
point is that thread identity alone may not be sufficient context to make a
choice. (And if people will be "overwhelmed" by passing around pools,
imagine how they will feel trying to figure out ThreadLocals!).

> At least when in comes to ForkJoinPools
> because all tasks are supposed to be CPU bound. So if you processing
> your request in a thread with a high priority, you also want to be able
> to sort you big array with a high priority.
> Likewise while running with a thread with a low priority you don't
> want to block high priority requests because your library uses the same
> pool for all your requests.
> Thats why I think something like
> Thread.currentThread().getForkJoinPool();
> would be appropiate

That is one context and obviously in this context you are making a property
of the thread the determining factor. But expand that a little and suppose
that some actions of a "low priority" thread can actually be high-priority,
so that task may need a different pool - now thread identity no longer
serves.

I do not see a way to generalize the mechanism by which you can have library
method like getForkJoinPool()  always return the "right" 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.
> >
>
> Normally you will just have a single FJPool in your system. Ideally a
> single FJPool with NumberOfProccessors threads should be adequate for
> most programs. Job submissions are queued up FIFO wise internally.

But you just said you wanted different pools for different priority tasks ?

I don't agree we only need one FJPool per system - it depends on how it is
used. It depends on whether it needs to encapsulate something inherent to
the particular library involved. It depends on how it performs for a given
workload.

> > Which would perform better: one pool of N thread processing 2
> > arrays, or 2 pools of N/2 threads processing 1 array each?
> The first one. Say you have 2 pools and the first pool sorts the array
> real quick because it is easier to sort (smaller/ semisorted/...). The
> second pool has a more work to do while sorting its array. But because
> you are using two pool the threads from the first pool are unable to
> steal tasks from the second pool and you are basically only using half
> of your CPUS/cores.

I was asking in the context of equal workloads. Also performance here is
relative - the "system" may perform better in one context or the other, but
what about individual threads? What if you are concerned about response
times as well as system throughput?

I do not see a one size fits all solution here, or even a one-size fits
many. There is so much context dependency here, the choices about how pools
are created and how they are used, has to come from a knowledgeable entity
in the "application".

Cheers,
David

> Cheers
>    Kasper
> _______________________________________________
> 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