From: [email-masked] (John Kapenga)
Date: Sat, 16 Jan 93 02:01:08 EST

hi;

It was my feeling that the concepts of group and context,
that were clearly understood differently by different people at
the start of the discussions, became somewhat better agreed on as
the pt2pt discussion took place.

Groups - used to define groups of processors for collective communication
	primitives and to allow mapping topologies onto processors. This
	allows a group of processors to be used in isolation to compute
	together.
Contexts - As Tom (and Tony) express below,

> From: [email-masked] (Tom Henderson)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Re: Communication contexts
> Status: R
> 
> 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 only expression stated so far about the difference between tags and
contexts I had gleaned was that context should now be wildcardable (IE no
-1 for All contexts) while a receive ALL or some other MASK variant would
be allowed on tags.

> 
>     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.)

Add:
      5d) A context is not strictly managed, but use should follow 
          suggested guidelines.

This could allow static allocation of contexts when reasonable, but also
support a context server (as the Postmaster General in Zipcode). Think
of the static contexts or non-registrar provided contexts as reserved
with respect to any registration system. This could be part of the
MPI initialization call, if a registrar is included.

The drawback here of course is the user could violate whatever guidelines
were given.

It seems to me most types of name registration or stack allocation schemes,
that are not too restrictive and allows user code to interact, are likely
to allow errant management of contexts as well.

I expect that allowing 5d) would let strictly controlled context systems
to be built over MPI.

> From: Tony Skjellum <[email-masked]>
> Message-Id: <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Re: Communication contexts
> Status: R
> 
> In Zipcode, contexts have a group-wide scope.  Groups of processes can

Of course if we eliminate groups from the pt2pt call then contexts may
not be explicitly limited to groups in MPI. (though a context server
could be asked to provide a context relative to a group).

> 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
...
> 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.

I expect the use push/pop for context state would make implementation
in some environments hard and I have some concern about requiring registration
on very large systems. I do think a strictly controlled stack context
system could be built over 5d).

The question about context management relates to how high a level MPI
should be at. I see it at a low level, that higher level systems can
be built on. That is one reason for keeping context management
"advisory".

> -Tony

I liked the zipcode documentation. I think it would be a good idea to
make it available on netlib.

john