Contact: David C. DiNucci
NASA Ames Research Center
Moffett Field, CA 94035
Voice: (650)604-4430 Fax: (650)966-8669
Much effort has been focused on various message-passing APIs for parallel communication: e.g. PVM, MPI, U-Net, Nexus, VIA, Fast-Messages. While each has certain benefits, all are based upon a paradigm where data is copied from one process to another, with the understanding that the API will serve optimally only when the source and destination processes are on different processors which do not share some memory. If communicating processors do share memory (or are the same processor), a different set of "shared memory" APIs may provide greater efficiency by avoiding copying overhead.
To write architecture-independent code, the programmer can either exert significant effort to dynamically check and switch between APIs as needed, or can use a message-passing API while accepting the fact that less-than-optimal performance will result in some cases, or may drop the idea of using an API and instead try a new (and still unproven) language such as HPF, CC++, etc. (which simply moves the same problems to the compiler writer). This problem is becoming even more acute with the acceptance of hybrid MPPs and clusters containing multi-processor nodes, where some processes will end up sharing memory and some won't, and DSM systems, where either a shared-memory or message-passing implementation may be optimal in different cases. Even though some options exist to correct these problems, lack of standardization thwarts their use.
The purpose of this meeting is to ask whether we are ready to begin standardizing (or at least supporting) an API which largely avoids these problems by enforcing a single flexible (and hopefully simple) semantics for inter-process communication which can be easily and efficiently implemented using either distributed copying (i.e. message passing) or access in place (i.e. shared memory without copying) approaches. If we are not ready, the meeting should end with recommendations for future study, or reasons that the goal is unattainable or undesirable. To provide a solid base for discussion, strawmen such as (but not necessarily limited to) the Cooperative Data Sharing (CDS) system and TreadMarks will be considered.