Subject: Re: Reply to Lyndon

From: [email-masked] (Al Geist)
Date: Thu, 4 Mar 1993 12:50:03 -0500

>is to be able to receive a message from any member of the process group.
>If we frame point-to-point in terms of some opaque (global) task
>identifier type then how can we provide the very expressive
>receive selection above?

The receive side is easy, and if you REALLY mean process group above
then the send side is also. But if you refuse to use the rank in a group
then knowing who to send to is the trick.

>Either one includes the task creation in the source code of the program
>Or one puts the task creation outside the program...

Putting it outside only works for multprocessors. What if you have
multiple multiprocessors or just a bunch of workstations on a network?
Users would have to write a separate (non-portable) program just
to start up their applications.
The argument still boils down to portability.

>Why don't we email vote on this? 

My vote is dynamic model

>Unfortunately it is the burden of a standards committee that it should
>standardise only agreed existing practice,

This is what I read as one of our original GOALS in MPI.
But that is not what I see happening.
We either need to stick to the original goal and drop all the "fringe"
stuff out of the communication specification, or 
we take a consistently forward-looking approach 
(which can't possibly be agreed on in two more meetings)
but may be the only way that we

>can ensure to avoid this apocalypse?

Al Geist

---

From: [email-masked]
Date: Thu, 4 Mar 93 13:21:44 PST

> to start up their applications.

I am puzzled by these words.  

There is at least one package (TCGMSG, by Robert Harrison) that uses
external invocation and works quite nicely on workstation networks as
well as multiprocessors.  

In TCGMSG, the programming interface is that the application just
calls PBEGIN_(argc,argv) to initialize, then finds out the number of
participating processes by calling NNODES().  (This is a static
process model.)

For workstations, TCGMSG supplies a general purpose program to start
up application processes.  It works by passing them command-line flags
that allow them to find each other.  The application does not need to
worry about these flags, because they are handled by the PBEGIN_ .  On
multiprocessors, other procedures may be used.  For example, on the
DELTA, the application processes are initiated by the Intel utility
'mexec', and PBEGIN_ works by calling the Intel intrinsic numnodes().

> The argument still boils down to portability.

Exactly.  As discussed above, the start-em-up-externally approach used
by TCGMSG allows a program to execute without change across widely
varying environments, with no need for the application programmer
to write non-portable code.

It would have been extremely difficult, verging on impossible, to
support an interface that explicitly allows an application to create
new processes on the fly.  (That capability is not provided by the
DELTA operating system.  But they do support sockets, so I guess you
could have a demon on some other system that would rsh back to the
delta and do another mexec, then use some undocumented and risky
system interfaces to pass messages between the nodes of the two
mexec's, and then...  But that doesn't seem very robust.)

> >Why don't we email vote on this? 

I propose that MPI simply mandate the existence of a capability to
start up processes externally.  Those processes find themselves
executing spontaneously and then find out about the others by making
MPI calls.  The syntax and semantics of the MPI calls should be
specified completely, but we should not say anything about the
external capability except that it exists.

--Rik Littlefield

---

From: Tony Skjellum <[email-masked]>
Date: Fri, 5 Mar 93 09:01:26 CST

Rik,

Using the Delta's lack of an elegant process model to defend your point is
not really valid.  They could have supported dynamic process creation, but
just were too busy with other things, and did not see how useful the previously
supported feature(s) were from iPSC960 and iPSC/1&2.

The real issue is whether anything is lost/gained by separating spawning and
MPI messaging.  Why might there be?

1) ability to spawn processes in a way to take advantage of special group 
properties (hierarchy in the memory/network access).  Oh well, the user can
still do this him/herself, and then tell MPI that the group has a special property.

2)  ability to support dynamic process model to allow MPI to serve as a base layer
for additional services.  For true portability, I would like to avoid having MEXEC
on Delta, and spawn() functions on iPSC860 and CE/RK, and so on.  

The lack of a well-understood need for group, so that group-scope operations,
can be attributed to a group, have not been recognized in MPI.  As each group
might want to implement a different broadcast or combine or other operations,
the lack of a well-formed group concept is the bottleneck to this discussion.

I am sleepy, I can't think of more now.

- Tony