[concurrency-interest] ForkJoinTask.externalAwaitDone() co-operates only with commonPool?

kirk at kodewerk.com kirk at kodewerk.com
Mon Feb 6 01:47:45 EST 2017


A while back I sifted through f-j and sorted out a way to instrument it with JMX. I am sure that my hack wasn’t the best way to instrument f-j but it did give me the information I needed at the time. Given the importance of the common thread-pool and f-j I am wondering if it might be a good idea to explore a way to add instrumentation so that important metrics can be exposed via the Platform MBean server to improve observability in the runtime?

Kind regards,
Kirk Pepperdine

> On Feb 5, 2017, at 10:44 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 02/05/2017 11:33 AM, Ruslan Cheremin wrote:
>> May be I miss something important, but I can't see in code how do
>> threads tries to help:
> Oh, sorry to misinterpret your question. "External" threads
> (non-ForkJoinWorkerThreads) by design do not help normal pools,
> which makes them act like other ExecutorServices.
> (I was referring to "internal" threads in previous answer.)
> But they must help in commonPool, mainly because the
> commonPool might not have any workers, due to system-wide
> policies. Doing it this way enables parallelStreams etc to
> still work in managed environments (although with no
> possibility of speedup). But this is an add-on to
> ForkJoinPools that doesn't apply in general.
>> Is it because there is no way to find out to which FJPool given FJTask
>> was submitted?
> Yes, although that's more of a consequence rather than a cause.
> -Doug
> _______________________________________________
> 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