Subject: context creation

From: [email-masked]
Date: Mon, 15 Mar 93 14:54:24 PST

The new point-to-point proposal distributed on 3/15/93 seems to
be generally well thought out.

However, there is a simple application program design that I do
not see how to implement using only the proposed context-forming
routines.

The same situation arose with the old group proposal, and I have
posted to mpi-collcom and mpi-context a suggested fix.  What
follows here is a similar suggestion for the new point-to-point
proposal.

The application design in question uses a master-slaves strategy
to asynchronously parcel out chunks of work, with each chunk
being done by several processes working collaboratively.  The
idea is that as chunks of work finish, the processes that were
assigned to them go into an idle pool, and when the pool gets big
enough, some processes are pulled out and assigned to the next
chunk of work.  Collective communication between processes
working on each chunk is required, so it seems natural to
organize them into MPI contexts.  However, using a synchronous
context partitioning routine, such as MPI_NEW_CONTEXT, is not
attractive because the varying chunk size implies that each group
of processes can finish their work at different times, and
synchronous partitioning would delay the assignment of new work
until all currently active chunks had finished.

This prompts me to suggest the addition of a less synchronous
context-forming routine.  This routine would be called only by
those processes wishing to join the new context, rather than all
processes belonging to the old context.

   MPI_FORM_CONTEXT (newcontext,oldcontext,nprocs,knownmembers,tag)
 
   where
     newcontext     is output as a handle for the new context.
     oldcontext     is a handle for the context that contains all
                      of the participating processes.
     nprocs         is the number of processes that will belong to
                      the new context.
     knownmembers   is a set of ranks, within oldcontext, of some
                      or all members of the new context.  Each
                      member of the new context must provide the
                      same set of knownmembers.
     tag            is a user-provided integer tag, sufficiently unique
                      to disambiguate overlapping contexts that might be
                      formed simultaneously (see discussion below)

In the appication design discussed above, the master would use
point-to-point messages in the ALL context to inform individual
processes of their assignments and collaborators, and the
processes assigned to each chunk would organize themselves by
calling MPI_FORM_CONTEXT.

The knownmembers argument specifies a set of processes that can
act as organizers of the context.  In earlier discussions, some
people have argued that group- or context-creation calls should
not have to specify all members because that would violate
scalability.  If knownmembers is allowed to be less than the full
set, then a tag is required to handle the case of overlapping
process sets being handled simultaneously.  Suppose that
processes 2 and 3 each attempt to form a 2-process context with
process 1, and process 1 is the only specified knownmember.
(I.e., process 1 makes two calls, each specifying a 2-process
context but not indicating which other process.)  Then messages
from 2 and 3 can be received at 1 in either order, and the tag is
required to keep things straight.  Personally, I would consider
it acceptable to require that knownmembers specify all the
members of the context, in which case there is no need for tag
because things are kept straight by sequencing.

Have I missed something about how to use MPI_NEW_CONTEXT?  

Is there a better way to implement this type of application than
MPI_FORM_CONTEXT, or does MPI_FORM_CONTEXT have some drawback
that I don't see?

--Rik

----------------------------------------------------------------------
[email-masked] (alias 'd39135')   Rik Littlefield
Tel: 509-375-3927                         Pacific Northwest Lab, MS K1-87
Fax: 509-375-6631                         P.O.Box 999, Richland, WA  99352