[OT] ParallelArray was RE: stack-bound vs. travelling closures proposal.

Nathan Bryant nathan.bryant at linkshare.com
Fri Jun 25 16:10:22 PDT 2010


Doug Lea wrote:

> 2. Code doing IO is not very amenable to "lightweight"
> closure processing, either in sequentially or in parallel.
> (You need heavier OS support to cope with blocked IO etc.)
> We effectively ban IO in ForkJoin framework by ...
> not allowing actions to throw checked exceptions!

It's also worth mentioning in passing, those folks doing blocking I/O,
or coarse grained parallelism of tasks of nonuniform size, in
ParallelArray are probably going to eventually notice the behavior of
the below--although it may or may not cause severe real world problems,
the call to r.atLeaf() can occasionally result in some surprising
serialization of the very last few items in a workload. Not a big deal,
I guess, since the biggest split is always going to be stolen first, and
then further split by the thief (right?)

        final void internalCompute(int l, int h, int g) {
            FJBase r = null;
            do {
                int rh = h;
                h = (l + h) >>> 1;
                (r = newSubtask(h, rh, r)).fork();
            } while (h - l > g);
            atLeaf(l, h);
            do {
                if (r.tryUnfork()) r.atLeaf(r.lo, r.hi); else r.join();
					     ^^^^^^^^^^^^^^^^^^^^^
                onReduce(r);
                r = r.next;
            } while (r != null);
        }


More information about the lambda-dev mailing list