By Rishiyur S. Nikhil (Bluespec) and Arvind (MIT)
There are many, many approaches to parallel programming, with a rich
terminology that can often be quite confusing. One often encounters
three terms to describe parallelism: parallel, concurrent, and
distributed.
Parallel Haskell (pH) sits
in the traditional space of "parallel" and "concurrent" languages. The
original motivation for, and the principal focus of pH research, has
certainly been parallelism for speed, just like traditional parallel
programming languages.
However, the
implicit parallelism in pH also subsumes the
concurrency in many concurrent programming languages, and pH may thus
be quite suitable for writing concurrent, nondeterministic, reactive
programs as well.
pH does not address issues of distribution. The closest that any pH
research has come to addressing distribution is in implementations of
pH for multicomputers and networks of workstations, but this
is still a relatively unexplored area.
In applications with a client-server architecture, pH could of
course be used to code either or both sides of the interaction, but it
is no different from other languages in this regard. (See "Calling Hell from
Heaven and Heaven from Hell" for
examples of how this has been done with Haskell.)
There are two aspects of pH that remain fairly unique. First, pH has
no explicit "processes" or "threads" to introduce parallelism; in
principle, everything executes in parallel except as modulated by data
and control dependencies (conditionals). Since pH's model clearly
subsumes a model with explicit threads, what are the advantages of
explicit threads? The issues revolve around efficiency of
implementation.
Second, pH's fine-grain, implicit synchronization on data access, as
seen in I-structures and M-structures, described in Part 7 of
this series, is quite unusual.
The concept of monitors, introduced by Hoare in 1974 [17], and
reproduced in several more recent languages including Java
(synchronized classes), is an example of implicit data synchronization
- synchronization is associated with a piece of data and happens
automatically on procedure (method) entry and exit.
However, the programmer still chooses which data should be protected
in this manner, and the granularity is often very large. In pH, on the
other hand the fine-grain implicit synchronization of I-structures and
M-structures enables the effortless exploitation of producer-consumer
parallelism in all its forms.
The only class of languages that are similar to pH in its implicit
parallelism is the class of parallel logic programming languages (see "Design of the
Kernel Language for the Parallel Inference Machine") and their more
recent descendants, concurrent constraint languages (see "Object
Oriented Concurrent Constraint Programming in Oz").
These languages are relational in nature, unlike pH's more familiar
functional basis. Many of these languages also have parallelism without
explicit processes and threads, and they also have implicit,
fine-grained data synchronization with logic variables (similar to
I-structures). Like pH, these languages are also still research
languages.
Finally, we reemphasize that there axe many issues in programming
languages that are orthogonal to implicit parallelism, which pH does
not address. We have already mentioned issues connected with
distributed systems-sites, authentication, security, and so on. The
advent of the World Wide Web has surfaced new research issues such as
"mobile" programs ("bots") and security and information flow.