[concurrency-interest] forkjoin.ParallelArray and friends

Tim Peierls tim at peierls.net
Mon Aug 27 20:41:15 EDT 2007

On 8/27/07, Doug Lea <dl at cs.oswego.edu> wrote:
> Neal Gafter wrote:
> > 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.

I argued strongly for an interface-based API, but I've come to accept Doug's
<strikethru>dictum</strikethru>reasoning. :-)

Seriously, after playing with the current API for a bit, it seems to me that
we need a lot more experience using these FJ creatures before trying to
device interface-based APIs that are implemented in terms of them. Classes
come and go; interfaces are forever.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070827/9a48daa6/attachment.html 

More information about the Concurrency-interest mailing list