ken@gvax.cs.cornell.edu (Ken Birman) (09/17/90)
We are investigating C++ support tools for `coarse-grained'
synchronous processing across distributed workstations. This exploratory
project is a joint undertaking between Dave Forslund's group in the
Advanced Computing Lab at Los Alamos National Labs and the NY CASE
Center at Syracuse Univ. Nearly all the real work has been done by
Anand Rangachari, a grad student at SU.
We have developed some tools and support classes making it easier to
write C++ programs that use ISIS to implement a computational strategy
largely based on that discussed by Steele in his `Making asynchronous
parallelism safe for the world' paper in POPL '90. (See also Valiant's
`BSP' paper in August CACM and Forslund et al's paper in the '90
Usenix C++ conference proceedings).
The basic model is in many respects a generalization of the data
parallel programming style typical of Connection Machine programs:
1. There are lots of (maybe virtual) processors, each containing ONE
object. The processors themselves need not be homogenous.
2. One special object is a master. All others are servers.
The master controls the lifetimes and actions of the servers.
3. Processors communicate through a channel that supports (maybe
virtual) broadcast. Servers are addressible in some regular fashion,
and there is a way for the master to communicate with only subsets
of servers.
4. All servers share the same behavioral interface. This is enforced
by the requirement that all servers contain C++ methods that are
known and callable from the master. This means that all servers
are instances of the same C++ base class, or a subclass thereof.
5. Computation proceeds by the master invoking one method for
some or all servers, waiting for them to finish, then invoking
another, etc., until master termination.
6. Server methods proceed in a (perhaps virtually) synchronous manner.
A set of explicit restrictions and support classes are needed to
avoid nondeterminism and apparent asynchrony.
7. Data access for masters and servers are restricted to statically
checkable safe methods. There are a lot of cases, each requiring
explicit support mechanisms that we are working on. Most
rules are embodied in the notion of commutable operations
described by Steele.
We have some grandiose plans for ultimately integrating support for
this kind of model across varying levels of gramularity, so that it
applies equally well across fine-grained Connection-Machine-style
parallelism, lightweight processes, and distributed systems.
(We are well aware of the communication bottleneck problems of
broadcast-based master/server computation. We think we can adequately
address these with a combination of raw speed (e.g., FDDI) and data
access restrictions that are already implicit in the data integrity
rules.)
Our initial work does NOT support the full model outlined here.
We don't do any static checking about commutable operations,
we require all servers to be of the same class; not subclasses,
and so on.
Of course, we are using ISIS because of its support for
* Heterogenous processors
* Broadcast
* Virtual synchrony
Our first pilot implementation is based on Master and Server class
templates (classes `MNI' and `SNI') that handle all of the ISIS calls
and related bookkeeping. Programmers must specify their particular
master and server classes via a scheme similar to that used with Sun
`rpcgen' (in fact, the generator `nigen++' is a modified version of
rpcgen). Nigen++ generates the actual C++ classes in which all public
server methods are turned into ISIS entries. Computation proceeds via
the kinds of simple master/server strategies described in the ISIS
documentation.
Thus, we have NOT tried to come up with an entire C++ front end
for ISIS; we are only class-ifying the functionality we happen
to need. However, this might serve as a basis or model for more
complete C++ support for ISIS.
This code is functional and apparently portable. It is running right
now on clusters of SparcStations. If you'd like a copy, just ask.
Keep in mind though that this code is not very polished, and will
be constantly evolving.
Doug Lea dl@g.oswego.edu || dl@cat.syr.edu || (315)341-2688 || (315)443-1060
|| Computer Science Department, SUNY Oswego, Oswego, NY 13126
|| Software Engineering Lab, NY CASE Center, Syracuse Univ., Syracuse NY 13244