[concurrency-interest] ForkJoinTask.externalAwaitDone() co-operates only with commonPool?
cheremin at gmail.com
Sun Feb 5 16:58:59 EST 2017
>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)
Oh, so it is for purposes of fallback/graceful degradation. Very
interesting, thank you for pointing this out, Doug.
But doesn't it put additional overhead on commonPool? I mean, every time I
use .join() on non-commonPool tasks, current thread tries to steal task
back from commonPool workQueue(s), which is never succeeded, but probably
do some cache trashing anyway?
2017-02-06 0:44 GMT+03:00 Doug Lea <dl at cs.oswego.edu>:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest