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

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri May 9 08:46:52 EDT 2014


To be honest, I don't understand why "nested" parallellism occurs at all.

1. flatten
2. recreate the shape

unless you are dealing with infinite streams; in the latter case the 
order of processing is extremely important, and it is no longer 
"uncontrolled" parallellism.

Alex

On 08/05/2014 09:48, Christian Fries wrote:
> Dear All.
>
> With respect to the improvement of the documentation suggested
>
> Am 06.05.2014 um 01:09 schrieb Doug Lea <dl at cs.oswego.edu>:
>
>> Sorry that you and a bunch of people at stackOverflow spent so much time
>> on this because you did not did not notice the java.util.stream documentation
>> (http://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html)
>> about the use of independent functions/actions (especially not those including
>> synchronization). We should do something about this.
> I would like to add two aspects from a user perspective:
>
> First, the linked page ( http://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html ) does not mention the ForkJoinPool or Managed Blocker, etc. at all. The words „pool“, „common“, „fork“, „managed“ do not even occur in the document. It is just a discussion of parallel streams from the stream perspective suggesting that code like the one I have used (thread save, no interference, etc.) works fine. (This is not actually my observation, it was a comment on SO).
> So a footnote that the backend of parallel streams is currently the FJP and that corresponding limitations apply (use of managed blockers) should be added (on the other hand - I would prefer to have the streams framework work without too much knowledge of the underlying implementation).
>
> Second, I would like to comment on the idea to „forbid“ nested parallelism at all: From a user perspective I try to (or have to) use parallelism a lot. In my library many parts are functional, stateless, free of interference. If you use parallelism a lot it may be that you have parallelism encapsulated „inside“ many small parts and nested parallelism is a natural thing. It is also a good thing. If I have an outer parallel loop of 5 on our 64 core machine it would be a waste to forbid inner (nested) parallelism. Everyone of the 5 could work on its task with a parallelism of > 10 - so we are talking about a factor of 10. - I have this situation in my lib and it works great.
>
> Of course, one aspect of the issue in my previous post is that we are submitting to a COMMON thread pool. A workaround would be to use a dedicated pool for each inner loop. But a common thread pool is an advantage, since it allows to globally control parallelism!
>
> Best
> Christian
>
>
> _______________________________________________
> 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