Subject: Some notes on MPI

From: [email-masked] (David C.P. Linden)
Date: Tue, 16 Feb 93 08:15:38 -0500

[I work with Ed in Digital's Massively Parallel Systems Group.]

>Data hiding via opaque types should be used unless there is a truly
>justifiable reason.

This means that, unless there is good reason, the user gets a cookie
and must use cookie-manipulation routines to perform actions.  A major
example is process ids.  We think PVM took the better approach by
having PIDs be opaque integers.  This allows processes to join and
leave, which MPI seems to rule out, but which we think should be
reconsidered.  Having the notion of 0..n-1 or 1..n may have some level
of convenience, but we think it is too restrictive.  (Additionally,
there is the paradigm problem.  0..n-1 is the C way of numbering, but
1..n is the FORTRAN.)

>A message type registration facility should be considered as an alternative
>to communication contexts.

A big problem we see with communication contexts is that they aren't
thread-safe.  Their purported purpose is to ensure different pieces of
code (e.g., libraries, user codes) don't conflict with each other in
the space of types.  That's a real problem worthy of solution, but the
lack of thread-safety in communication contexts casts doubt on CCs as
a solution.  A type registration system (compare (very loosely) the X
windows color space registration system) would allow users and
libraries to allocate and deallocate a range of types.  With
appropriate allocate routines, you could specify alignment constraints
in order to bit-encode semantics.