[concurrency-interest] ParallelArray updates du jour

Doug Lea dl at cs.oswego.edu
Mon Jan 21 07:40:22 EST 2008

> On Jan 18, 2008 1:47 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> In more concrete terms: I feel I could make good use of a high-level
> explanation of how the new API is helping me (the "concurrency dummy")
> solve
> problems more easily and more safely than the already existing concurrency
> infrastructure. (I am not even sure which is the head and which is the
> tail
> of this API beast.)

Tim Peierls answered in terms of underlying mechanisms,  (BTW,
Tim is playing a big role in developing the APIs for
these classes.)

Another way of answering is that Parallel*Array
(and planned follow-ons) provide an easier/better way of
routinely programming to take advantage of dozens to
hundreds of processors/cores: If you can think about a
programming problem in terms of aggregate operations
on collections of elements, then we can automate parallel execution.
This generally pays off if either you have lots of elements,
(in which case, it works well even if the operations are
small/cheap), or if each of the operations
are time consuming (in which case it works well
even if there are not a lot of elements).
To take advantage of this though, the
aggregate processing must have a regular structure, which
means that you must be able to express things in terms of
apply, reduce, filter, map, cumulate, sort, uniquify,
paired mappings, and so on. So that's what Parallel*Array
does. Some people (especially those with experience
with either database programming or functional programming)
like this style anyway, and might use this  API
even without the parallelism benefits. But in turn,
the fact that this style can be awkward to write out
has led to all the language extension controversies
about closures, function types, and related syntactic


More information about the Concurrency-interest mailing list