RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

Mike Duigou mike.duigou at oracle.com
Fri Jan 10 18:11:53 UTC 2014

On Jan 10 2014, at 05:42 , Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> Some tweaks to the Stream forEachOrdered operation:
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/
> The first tweak is to size the CHM used in ForEachOrderedTask, this avoids concurrent resizes and the costs associated with those.


> The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. 
> I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle).

Coud not the lock object be removed?


> Paul.
> [1]
>     * <p>This operation processes the elements one at a time, in encounter
>     * order if one exists.  Performing the action for one element
>     * <a href="../concurrent/package-summary.html#MemoryVisibility"><i>happens-before</i></a>
>     * performing the action for subsequent elements, but for any given element,
>     * the action may be performed in whatever thread the library chooses.
>     *
>     * @param action a <a href="package-summary.html#NonInterference">
>     *               non-interfering</a> action to perform on the elements
>     * @see #forEach(Consumer)
>     */
>    void forEachOrdered(Consumer<? super T> action);

More information about the core-libs-dev mailing list