[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