Subject: PRECIS for closure proposal

From: Tony Skjellum <[email-masked]>
Date: Mon, 8 Mar 93 16:10:45 CST

Please comment.
- Tony Skjellum

----------------------------------------------------------------------------
Here is the precis of the post-MPI meeting...  Input was from Skjellum,
Littlefield, Pierce, Ranka [and others I don't recall specifically].

There shall be three self-consistent "closures" for MPI, that completely
remove inconsistency between the usage of the following concepts
(while fully defining the following concepts):

1) tag
2) context
3) group
4) process ID

It is our task to assemble such proposals and to place them before
the context sub-committee prior to the next meeting, and provide a
refined set of proposals (with recommendations) before the full committee
at the next MPI meeting.   The first reading of this section of the
standard is needed to make the rest of the standard go forward.

---------------------------------------------------------------------

Proposal I.  GROUP ID = CONTEXT = OBJECT, aka "Snir" model

groups, contexts, objects are local and opaque.
naming of processes is group-relative.

this option was discussed, in most part, by Snir at meeting.

Proposal II. GROUP ID != CONTEXT, aka "Littlefield" model

GROUP corresponds to "data/instance" in this model
CONTEXT is statically defined at link time, corresponding to
	code or class

In this model, group ID's appear explicitly, and separately
from CONTEXTS in global operations.  It was noted by Littlefield
that he would write global operations, and product bits of the
GROUP ID and static CONTEXT to guarantee that his code produced
unique, deterministic, non-interfering results.

Proposal III. GROUP ID null, GROUP scope == CONTEXT scope, aka Zipcode model

CONTEXT is a dynamic concept, and global (or as global as necessary)
Whenever a group is created, a context is assigned to it.  CONTEXTS
are used to disambiguate global operations.

GROUP ID is the CONTEXT for the group.  

GROUP is an enumeration of PROCESS ID's OR ONE OF SEVERAL
	possible hashing formulas, with exceptions (more scalable)

Proposal IV. GROUP ID != CONTEXT, aka fully "object-oriented" model

CONTEXT is a dynamic concept, and global (or as global as necessary)
GROUP ID is emasculated, in the sense that there are process groups,
but CONTEXT is still needed in global operations

The general case of "code U data" (the object-oriented model) is
taken, with context+group forming a scope in the system.

The "Server model," where CONTEXTS that have no group association
made to them, is to be supported.

GROUP is an enumeration of PROCESS ID's OR ONE OF SEVERAL
	possible hashing formulas, with exceptions (more scalable)

----------------------------------------------------------------------

Requirements for all proposals to meet closure

1) All global operations must be describable in terms of point-to-point
operations without loss of generality

2) Global operations, including non-blocking barriers, and so on, must work
correctly with overlapping process groups

3) There must be reasonable/scalable mechanism for assigning contexts

4) Tag usage seems to be non-controversial according to above discussion,
but we need to watch out for the following.

1) desire to use part of tag for context, group ID or other field,
	and make that part of the standard

5) Provision of enough contexts to support all describable or reasonable
	scenarios that we can justify, but not more than are foreseeable,
	because there could be a performance penalty by requiring the
	number of contexts to be too great.

6) Justification is perceived to be required for dynamic contexts (why?)

7) A fully consistent definition for how process IDs are to work.

8) An explanation of how to extend to dynamic groups later, if possible.

---

From: William Gropp <[email-masked]>
Date: Tue, 9 Mar 93 17:13:30 CST

The one point in Tony's excellent summary that needs more elaboration is 
needed on whether process id's, when being used in point-to-point operations,
are group-relative (ranks) or absolute (and possibly opaque). Only Proposal
I specifies this (ids = ranks); the others leave this unspecified.  In the
interests of keeping the latency down, I'd like them to be absolute, at least
at the lower levels.  In any event, this choice is a critical one but one
that is mostly orthogonal to the other issues.  In fact, I'd have chosen
absolute process id's as the "Snir" model.
Bill