Subject: discussion of process dynamicism, publish, subscribe, etc.

From: Tony Skjellum <[email-masked]>
Date: Sat, 10 Jul 93 16:09:42 CDT

Dear colleagues,

Adam Greenberg and I have been discussing the issue of dynamicism in the
context chapter (publish, subscribe, possibility of dynamic process management
outside MPI, etc).  Please comment...

- Tony
-------------------------------------------------

---

From: L J Clarke <[email-masked]>
Date: Mon, 12 Jul 93 09:55:35 BST

Some comments as requested.

> >From [email-masked] Fri Jul  9 11:11:00 1993
> From: Adam Greenberg <[email-masked]>
> Date: Fri, 9 Jul 93 12:10:49 EDT
> To: [email-masked]
> Subject: discussion
> Content-Length: 972
> X-Lines: 19
> Status: RO
> 
>    Date: Tue, 6 Jul 93 19:06:11 CDT
>    From: Tony Skjellum <[email-masked]>
> 
>    I would like to discuss your concerns about inter-group
>    facilities, and get you involved in the revised context
>    proposal, prior to next meeting.  Can you summarize
>    worries, and how we can allay them reasonably, without
>    giving up MPMD programming capabilities.
> 
> I don't think you can allay my fears.  I (as TMC) don't believe that MPI should
> contain mechanisms for coupling disparate programs together.  

I share this belief.

> I distinguish
> this notion from MPMD in which all of a user's programs which comprise an
> instance or invocation of the users `system' are known a priori and information
> on all members of the system is available at system start up. 

The validity of this distinction is restricted to a world in which the
MPI user cannot dynamically create processes.  I guess its a bit harder
to describe the distinction when the user can do this.  Nevertheless I
have an intuitive understanding of the distinction which I believe is
useful. 

By the way, I do not think that information regarding all members of the
user "system" really is available at start up - to the MPI user - at
least not all information on all members available to all members - and
certainly relevant information which does not yet exist is not
available. 

> Intersystem
> communication is properly an OS issue.  

Yes.

> It has already been solved by Unix.

No. 

> Other solutions too, we believe, will require OS support if not implementation.
> These OS related requirements are beyond the scope of MPI.

Concur.

> >From [email-masked] Sat Jul 10 15:09:11 1993
> From: Adam Greenberg <[email-masked]>
> Date: Sat, 10 Jul 93 16:09:01 EDT
> To: [email-masked]
> Subject: discussion
> Content-Length: 193
> Status: RO
> X-Lines: 7
> 
>    Date: Sat, 10 Jul 93 15:04:11 CDT
>    From: Tony Skjellum <[email-masked]>
> 
>    What about dynamic process management for a single user?
> 
> What do you believe this to entail?
> moose
> 
> >From [email-masked] Sat Jul 10 15:56:59 1993
> From: Adam Greenberg <[email-masked]>
> Date: Sat, 10 Jul 93 16:56:53 EDT
> To: [email-masked]
> Subject: discussion
> Content-Length: 1374
> Status: RO
> X-Lines: 30
> 
>    Date: Sat, 10 Jul 93 15:13:58 CDT
>    From: Tony Skjellum <[email-masked]>
> 
>    Well, it used to be possible on some systems for the "HOST program"
>    and even other node programs to spawn processes, kill processes,
>    as needed, rather than having everything "known at the beginning."
>    To be concrete, on the iPSC/2 and iPSC/860, it is possible to "spawn"
>    and "kill/killcube."
> 
>    It would be nice if we could support, however weakly, the ability to
>    cope with such dynamicism.  It is arguable that a spawn mechanism
>    would return a communicator for the spawned child, and the spawned
>    child would get its MPI_COMM_PARENT set accordingly.  With flatten/unflatten,
>    the child could be told about other SPMD groups, without an explicit
>    publish/subscribe mechanism.
> 
> The child could be told about other groups, but it would be unable to
> participate in any communication unless other processes were told of its
> existence.  This begs the issue of how to introduce (or delete) new processes
> to (or from) the global process pool.
> 
> Will the exclusion of this functionality severely cripple many would-be MPI
> users?  Will it cripple MPI acceptance?  Will it be difficult to include at a
> later time - MPI2 were it to happen?
> 
> My opinion is that its exclusion is not a real problem.  However, I will
> certainly listen to arguments to the contrary.

I believe that exclusion will not cause a large problem in the short
term but will lead to the dismissal of MPI as a standard within the not
so distant future.  However, it will mean even in the short term that
there will be work which is prevented from use of MPI as a direct result
of this exclusion. 

I can't claim to know what will be a good approach to dynamic process
management.  I have ideas, which in part seem to make sense to me, but
are, to the best of my knowledge, quite untested.

5c

Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: L J Clarke <[email-masked]>
Date: Tue, 20 Jul 93 12:40:43 BST

> I share this belief. [Lyndon]

There may be a misunderstanding here. 

IF you (Adam) mean that by "disparate programs" different program texts
- in other words you (as TMC) believe that MPI should only address SPMD
programs - then I strongly disagree with you.

IF you (Adam) mean different MPMD systems, as you describe below, then I
strongly agree with you. 

Is this crystal clear? I hope so!

Best Wishes
Lyndon