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

Christian Fries email at christian-fries.de
Tue May 6 09:01:14 EDT 2014


Hi Paul.

Oh. I expected that it would be countered that „Thread.sleep()“ is not be a legitimate test case… ;-)

I have update my demo and now I use a stupid for-loop summing up some cosine to burn real CPU time. The result is

Nested stream forEach: outer parallel, inner sequential:	34 sec
Nested stream forEach: outer parallel, inner parallel:		63 sec

In the first case my 8-core CPU ist working at 800% all the time. In the second case you can clearly see that its almost idle at certain times.

You find my updated test case here:
http://svn.finmath.net/finmath%20experiments/trunk/src/net/finmath/experiments/concurrency/NestedParallelForEachTest.java

If you like to not use Thread.sleep() set isCPUTimeBurned to true - you might need to calibrate that count used in the loop.

Best
Christian


Am 06.05.2014 um 12:47 schrieb Paul Sandoz <paul.sandoz at oracle.com>:

> Hi Chris,
> 
> 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:
> 
>     interface Blocker {
>         void block() throws InterruptedException;
>     }
> 
>     ForkJoinPool.ManagedBlocker blocker(Blocker b) {
>         return new ForkJoinPool.ManagedBlocker() {
>             boolean finished = false;
>             @Override
>             public boolean block() throws InterruptedException {
>                 b.block();
>                 return finished = true;
>             }
> 
>             @Override
>             public boolean isReleasable() {
>                 return finished;
>             }
>         };
>     }
> 
>   ForkJoinPool.managedBlock(blocker(() -> Thread.sleep(N)));
> 
> 
> 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.
> 
> I think we could do a better job documenting the hazards of nested parallelism. Also pondering if it is appropriate and possible to disable the parallelism on a nested parallel stream.
> 
> Paul.
> 

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


More information about the Concurrency-interest mailing list