[concurrency-interest] forkjoin.ParallelArray and friends

Doug Lea dl at cs.oswego.edu
Mon Aug 27 19:14:29 EDT 2007

Neal Gafter wrote:
> For example, if I have a parallel array a, I can perform 
> a.withMapping(...) to map it onto another sequence-like thing. But the 
> resulting thing doesn't have a withMapping operation, so it isn't 
> possible to apply a mapping (or a filter) after a mapping; you can't 
> a.withMapping(...).withMapping(...).  

Right. If you want to apply functions F and G, then you
must define a function/object GofF that combines them itself
to hand to withMapping.

We supply only something that knows how to do
select then map then {apply, reduce, etc} in one efficient
parallel pass, not an arbitrary function composition
library. (Someone else might want to take this on.)

Note: select-then-map-then-operate is a fairly well-entrenched
parallel idiom. We're trying to expose it in a way that is
both useful and efficient.

> I think the whole API should be interface-based.  For example, I think 
> the results of a.withMapping() should be the ParallelArray interface or 
> some subtype. 

We debated this. I think the current form is an OK compromise
between too little and too much abstraction. For example, to
properly generalize ParallelArray as an interface, you'd also need to
somehow generalize ForkJoinExecutor into something that would allow
say alternate ParallelArray implementations via say GPU parallelism.
Which then gets you into lots of bulky layers of interfaces and
factories before you can get anything done. Maybe someday we will
need such a thing, but if so, it can be retrospectively abstracted.


More information about the Concurrency-interest mailing list