[concurrency-interest] ForkJoinPool not designed for nested Java 8 streams.parallel().forEach( ... )

√iktor Ҡlang viktor.klang at gmail.com
Tue May 6 08:34:35 EDT 2014

On Tue, May 6, 2014 at 1:17 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 05/06/2014 06:47 AM, Paul Sandoz wrote:
>  I think the use of Thread.sleep is a little misleading, since it is a
>> blocking
>> operation. Try placing all those sleep statements in managed blocks and
>> you will
>> get different results e.g. with:
> Yes. We ought to provide this. I suppose we could intercept
> java.lang.Thread.sleep to do it automatically,
> but just adding ForkJoinTask.delay(timeout) would help.
> Similarly for CompletableFuture.
>  Assuming *non-blocking* operations an enclosed (nested) parallel stream
>> will
>> compete for the same common pool resources with the enclosing parallel
>> stream,
>> something i have advised against doing. I don't know if that would be
>> significantly different from equivalent work performed by two independent
>> parallel streams executed concurrently; need to measure as Russel says.
> There's a fun story here. FJ is fully capable of keeping up with
> nested parallelism, but some of it is internally disabled, so nested
> forms will (only) sometimes run in a slow emulation of sequential
> processing. In versions prior to JDK7 release, continuation-thread
> compensation generated spare threads to maintain target parallelism.
> This works great for correctly expressed nested parallelism but is
> prone to positive feedback loops when people make small design errors
> like inverting joins. When mixed with blocking IO, we saw cases where
> this generated thousands of threads. So for the sake of JVM stability,
> compensation is restricted to cases where the pool is saturated. This
> could be re-explored.

Speaking of which—is there anything that prevents adding the capability to
specify the maximum number of threads allowed to be spawned due to managed
blocking? (The current default blows up about every JVM there is.)

> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140506/2aa2eac0/attachment-0001.html>

More information about the Concurrency-interest mailing list