[concurrency-interest] Work-stealing ThreadPool
radhakrishnan.mohan at gmail.com
Fri Apr 20 00:58:41 EDT 2012
Are there many OSS frameworks that use FJ in different ways to understand
these requirements ? The
wide adoption of these ideas could form a better sample space. Now it seems
that only specialized framework
developers use them.
I might be wrong because we don't have colleagues who are aware of some of
these advanced ideas.
On Thu, Apr 19, 2012 at 8:44 PM, Aleksey Shipilev <
aleksey.shipilev at gmail.com> wrote:
> Hi guys,
> There are multiple cases now when people are choosing ForkJoinPool over
> regular ThreadPoolExecutor because of improved submission throughput and
> work balancing. Can we embrace this fact and do proper isolation in API
> for this cases?
> I'm thinking public class j.u.c.WorkStealingExecutor implementing
> ExecutorService, but delegating directly to ForkJoinPool. If that is
> added to JDK7/JDK8, we can properly isolate these customers from
> exposing FJP underneath. Moreover, after this API is exposed, we can
> gradually replace FJP delegation with independent work-stealing
> executor, if ties with FJP will bother anyone.
> Are there any troubles with this proposal I missed?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest