CMP EMBEDDED.COM

Login | Register     Welcome Guest  
HOME DESIGN PRODUCTS COLUMNS E-LEARNING CONFERENCES CODE FORUMS/BLOGS NEWSLETTERS CONTACT FEATURES RSS RSS

Making the transition from sequential to implicit parallel programming: Part 8
Turning parallel Haskell (pH) into a production language



Embedded.com
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.

1 | 2 | 3 | 4 | 5

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Ready for a change?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS





 :