Subject: Communication contexts

From: [email-masked] (Dennis Weeks)
Date: Fri, 15 Jan 93 15:11:17 -0600

Rusty Lusk writes:
> David, perhaps you could create a mailing list on which this discussion can
> take place, parallel to the subcommittee mailing lists, so it doesn't have to
> go to the whole committee.  Thanks.
I believe the default inclusion of everyone is a good idea, although creating
a separate mailing list might be appropriate if some mpi-comm members wish to
"unsubscribe".  In the meantime, I will add one brief opinion:

I felt that the discussions of contexts in the topology subgroup were quite
sufficient, and it would probably be better to have the single subgroup which
covers both groups and contexts, so that both will appear in the standard in
a style which does not make them conflict with each other, and/or to avoid a
proposal where groups and contexts would be totally redundant.

I definitely agree that it is an important topic, and that the discussions
last week in Dallas were far away from getting a proposal for groups and
contexts that would be unanimously acceptable, so much work remains to be done.

---

From: [email-masked] (Tom Henderson)
Date: Fri, 15 Jan 93 14:59:49 MST

> | 
> | On the topic of communication contexts I think (at least) 4 approaches have
> | been proposed.
> | 	1) Implicit communication contexts as in MPI1 controlled by push/pop.
> | 	2) Explicit registration as in Zipcode
> | 	3) Explicit communication contexts should be merged with explicit
> |            group contexts. Since groups cannot communicate with each other
> | 	   a new communication context can be created by creating a new group 
> | 	   with the same members as the current group.
> | 	4) Chuck Simmons of Oracle has suggested that communication contexts
> | 	   are really a particular type of thread, and so can be handled
> |            using existing threads packages.
> | If you have any ideas, or are strongly for or against any of the above
> | approaches let mpi-comm know so we can initiate a discussion of this topic.
> 
> I think that 1) contradicts our genral agreement to avoid state as much as
> possible.  4) is a problem on systems that don't support threads, and we have
> more-or-less agreed to be consistent with thread packages but not depend upon
> them.  3) should be discussed along with the converse: that contexts rather
> than groups should be the primary concept and groups defined in terms of
> contexts.
> 
> Rusty

I'm not sure, but I believe that Zipcode uses push/pop to control contexts 
(Tony, please correct me if I'm wrong).  I'd like to add a 5th approach, 
basically the one proposed by Paul Pierce:  

5)  Contexts are used exclusively to insure that message collisions will not 
    occur if independently developed sub-programs are combined.  Contexts and 
    groups are orthogonal.  Contexts and threads are orthogonal.  Each message 
    has an associated context and tag.  Message context is managed by library 
    routines and is completely out of a user's control.  Message tag is 
    selected by the user.  

    The method of managing message contexts is a separate issue (assuming we 
    want contexts).  Existing proposals are:  

    5a)  Stack-based management (objected to due to hidden states).  
    5b)  Explicit registration with user-defined "names" (probably requires 
         some communication).  
    5c)  Explicit registration by a central authority ("dollar bill" 
         registration mentioned by Jim Cownie.)

There is enough confusion about contexts and groups that we may want to keep 
this discussion open to everyone.  If the concensus is to make a separate 
mailing list, please both of us to it.  

Thanks,

Tom Henderson
[email-masked]

Leslie Hart
[email-masked]

---

From: Tony Skjellum <[email-masked]>
Date: Fri, 15 Jan 93 18:05:36 CST

In Zipcode, contexts have a group-wide scope.  Groups of processes can
involve more than one context.  For instance, if 10 processes are involved
in several stages of a calculation, each stage might have a different notion
of how to do messaging, but each would use all the processes.  Groups
are important, because they allow control over the scope of global operations.
Contexts are important because they provide guarantees to sub-programs
about restricted scope of messages.  Contexts are added typing-like
information, but which is controlled by the system, not ad hoc by each
user program.  When they determine to start messaging, sub-programs
request a context from a "postmaster general" in Zipcode.  Currently, this
is a group-oriented request (loose synchronization) resulting in each
group member getting the context, and other information.  In a lower-level
system, simpler tactics might be possible.  The way we did it was supposed
to avoid possibility of races or other problems like that.

To build large-scale software, without globalization of the local use of
messaging resources, and to provide scalable algorithms with efficient
global operations, both groups and contexts are needed.  The push/pop
state is an implementation detail of little importance.

-Tony