Subject: overview and "sketch VII"

From: [email-masked]
Date: Tue, 23 Mar 93 15:17:43 PST

Many thanks to Jim for his summary of various proposals.

The earlier proposals have become rather Talmudic, with layer
upon layer of comments so detailed that it is difficult to tell
what are the fundamental differences.  Even after integration of
the comments, proposals are now so long that they require much
study.  (Proposal VI is gonna take a while, Lyndon.)

Rather than comment further on Jim's summary or any other
specific proposal, I would like to sketch anew a possible
synthesis of key ideas selected from all the proposals.  

This is a somewhat expanded version of the sketch that I
distributed a couple of days ago with a confusing choice of
title.  Following both of Lyndon's suggestions, I will now call
it "Sketch VII".

My hope here is to provide a BRIEF description that may help
clarify our thinking and contribute to a unified proposal.

BASE FEATURES

Functionality

. All descriptors/identifiers are local and opaque.

. A "context" consists of a collection of processes that have
  agreed amongst themselves regarding context-relative process
  names ("ranks"), and have also negotiated a protection
  mechanism to keep contexts separate.

. There is a predefined context holding all the initial processes.

. Contexts are formed and destroyed by loosely synchronous calls
  in only those processes belonging to the context.

. Point-to-point messages can be sent and received within a
  context, in which case both sender and receiver are identified
  by rank.

. Groups are not equal to contexts.  From the user's standpoint,
  a group consists of a base context (from which other contexts can
  be created cheaply by copying), plus topology information, plus
  a facility for attaching arbitrary information to the group
  descriptor ("cacheing").

Performance/Implementation Expectations

. Assembling a new collection of processes requires communication
  and imposes actual synchronization.  The implementation is
  expected to be scalable and to cost no more than a point-to-point
  fanin/fanout on the participating processes.

. "Copying" a context does not require communication and does not 
  impose actual synchronization.  (Use a counting strategy.)

. There is no concept of a globally unique context value.  If
  desired by the MPI implementor, each process can choose its own 
  message selector value and broadcast it to the other processes
  upon context formation.

EXTENDED FEATURES

Functionality

. Process, group, and context descriptors can be passed around by
  special mechanisms.  This allows a process to obtain the
  descriptor for a group or context of which it is not a member.
  If a process receives a descriptor by one of these mechanisms,
  then that process assumes responsibility for explicitly
  releasing it when the descriptor is no longer needed or becomes
  stale.

. Point-to-point communications can be extended to allow a process
  to send a message to any context for which it holds a
  descriptor.  The receiver needs an easy way to identify and/or
  select on sender.  (Lyndon's proposal VI introduces an "open
  context" form that works well if sender and receiver hold
  descriptors for each other's contexts, but is not clear on
  how the sender is identified if the receiver does not know
  the sender's context.)

. Registration facilities can be added to allow global naming of
  processes, contexts, and groups.  The registration facility
  translates between globally unique names and process-local
  descriptors.  (I.e., to register a name, one specifies the name
  and matching descriptor; to lookup, one specifies the name and
  receives a descriptor in reply.)

  This capability, and none of the capabilities before it,
  requires an asynchronous server.

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