Subject: mpi-context: back-translation avoided

From: L J Clarke <[email-masked]>
Date: Wed, 30 Jun 93 19:28:14 BST

Dear Jim

How we avoid the back-translation which you discussed, is as follows... 

We tended to talk so far of this communicator having two basic fields,
CONTEXT and GROUP.  I guess we always thought that the SOURCE field of
the message envelope would be the rank of the sender in the group of the
communicator.  It might always have been an optimisation to store this
number as a field in the communicator rather than the group.  Let us
make SOURCE a basic field of the communicator, along with CONTEXT and
GROUP.  The SOURCE field of the communicator is copied into the SOURCE
field of the message envelope when the communicator is used for send. 

Examples:

I just give a couple of examples for intra-group point-to-point,
(intra-group) collective, and inter-group (point-to-point)
communications. 

To do point-to-point intra-group communication. 

Process P is a member of group G and has a communicator Cp which binds a
CONTEXT = C, GROUP = G, SOURCE = RANKp(G).  (here I use RANKx(G) as some
notation to mean the rank of process X in group G).  Process Q is a
member of F and has a communicator Cq which binds CONTEXT = C, GROUP =
G, source = RANKq(G).  P can send to Q the notation {Cp,RANKq(G)} and Q
can receive from P with the notation {Cq,RANKp(G)}, and vica versa.

I have not mentioned that the context C must be unique in P and Q --
meaning that neither P nor Q bind C to a different group in a different
communicator and use that communicator for receive.  This is the
security issue which concerns you, which is a different issue.  I will
just assume sensible use of contexts. 

To do collective (intra-group) communication.

For all processes P in group G, P has a communicator P which binds
CONTEXT = C, GROUP = G, SOURCE = RANKp(G).  The group G can perform
collective communication with the notation {Cp}. 

To do (point-to-point) inter-group communication.

Consider process P a member of group G and process Q a member of group
H.  Process P has a communicator Cp which binds CONTEXT = C, GROUP = H,
SOURCE = RANKp(G).  Process Q has a communicator Cq which binds CONTEXT
= C, GROUP = G, SOURCE = RANKq(H).  P can send to Q using the notation
{Cp,RANKq(H)} and Q can receive from P using the notation {Cq,RANKp(G)}.

(Aside: If we do not allocate a context which is "unique" in both P and
Q then we can use two communicators, one containing a context unique in
P which P uses for receive and Q uses for send, and the other containing
a context unique in Q which Q uses for receive and P uses for send.  In
this case the value of the SOURCE field in the communicators used for
receive is irrelevant.)

To do point-to-point inter-group communication in weaker senses. 

If a process P is not a member of a group G then RANKp(G) is some
constant say '-1'.  Let a process perform a receive with the notation
{comm, '-1'} which means any process not in GROUP(comm). 

Consider process P a member of group G and process Q a member of group
H.  Process P has a communicator Cp which binds CONTEXT = C, GROUP = H,
SOURCE = '-1'.  Process Q has a communicator Cq which binds CONTEXT = C,
GROUP = ?, SOURCE = ? (the "?" means that the detail is irrelevant in
this example).  P can send to Q using the notation {Cp,RANKq(H)} and Q
can receive from P using the notation {Cq, '-1'}. 

Rule:

This is a rule for the SOURCE field which avoids the implementation
having to do the expensive back-translation.  It ensures that the source
field of the envelope is immediately meaningful at the receiver as
either a rank in the group bound with the context or '-1' meaning that
the sender is not in the group. 

"It is erroneous for a process P to use a communicator C to send to a
process Q unless either the source field of C is the rank of P within
the group which Q binds with C or the source field of C is '-1'."

You will notice that this is not an easy rule to enforce, i.e.  it costs
in the implementation of communication if you do choose to enforce it. 

Did I go wrong somewhere?

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: Ian Glendinning <[email-masked]>
Date: Thu, 1 Jul 93 19:16:19 BST

> From: L J Clarke <[email-masked]>

> field of the message envelope when the communicator is used for send. 

[Examples deleted]

When I first read this I found it incredibly confusing.  Just when I'd got
used to communicators with only GROUP and CONTEXT fields...  However, I think
I now understand what you mean, and would just like to check that I've got
hold of the right end of the stick.  As far as I can tell, what you're
actually saying is that what is passed in the SOURCE field of the message
*envelope* should be the rank of the sender, rather than its TID, as in the
example implementation of Mark Sears that I posted the other day.  Is that
right?  I was confused by the fact that you dwelled on the optimisation of
caching the SOURCE rank in the communicator.

> {comm, '-1'} which means any process not in GROUP(comm). 

And here the SOURCE field in the message is set to -1.  Right?
   Ian

---

From: L J Clarke <[email-masked]>
Date: Thu, 1 Jul 93 19:22:38 BST

> right? 

yes - the rank that is stored in the SOURCE field of the communicator

> And here the SOURCE field in the message is set to -1.  Right?

yes - because it is '-1' in the SOURCE field of the communicator.

Best Wishes
Lyndon