Subject: RE: Communication contexts

From: Charles Simmons <[email-masked]>
Date: Sat, 16 Jan 93 03:08:56 PST

> |     4) Chuck Simmons of Oracle has suggested that communication contexts
> |        are really a particular type of thread, and so can be handled
> |            using existing threads packages.

> possible.  4) is a problem on systems that don't support threads, and we have
> more-or-less agreed to be consistent with thread packages but not depend upon
> them.  3) should be discussed along with the converse: that contexts rather

Allow me to clarify my sentiments.  The example of context usage given
in the MPI draft documentation appears to explicitly assume the
existance of threads, and here contexts appear to be being used as
threads.

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

I could strongly support almost all of the above.  [The part I
wouldn't support is a "tag" as I will explain below.]  We do our work
on the nCUBE, which, as you may know, has a message passing interface
essentially equivalent to that proposed by MPI.  We ran into the exact
problem quoted above: it was difficult to write libraries that
we're guaranteed not to conflict in their usage of message types.

The usage of the word "contexts" in the above is equivalent to the
usage of the word "ports" amongst operating systems programmers.
Because "port" is slightly less overloaded than "context", I prefer
the word "port".

Note that ports are sufficiently powerful that they subsume the
concepts of "contexts", "pids", and "message types" or "tags" as used
by MPI.

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

I agree that there is little difference between tags and contexts.
This helps explain why ports are so good at subsuming both contexts
and 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.)

I don't particularly understand the above, probably because I haven't
been listening in on enough of the discussion.  I think I understand
what you mean by stack-based management, and we do use the word
"registration"...

When using ports, stack-based management isn't an issue for the same
reasons you don't manage pids and message types using stack based
management.  For example, when sending a message, instead of using the
MPI

	push_context (contextp);
	send (dest, type, buf, buflen);
	pop_context (contextp);

you use

	send (port, buf, buflen);

In our usage, a "port" is simply a queue to which messages can be
sent.  The receiver can remove a message from the head of the queue.
Wildcards are neither needed nor implemented, making ports more
efficient.  The efficiency arises from the fact that a process can
have multiple ports.  In MPI, you essentially implement one receive
queue for each pid.  If you want to use a wildcard to access messages
out-of-order, you need to waste time scanning the queue.  With
multiple ports, however, you can set up multiple queues so that you
never need to access anything other than the head of a queue.

Sometimes ports do need to be "registered".  In our terminology,
registration is the process of publishing in a well-known location
sufficient information about a "port" created by one process that
another process can send messages to that port.  This is a very high
level action that is almost outside the scope of MPI.  We use a
nameserver for this purpose.  (The nameserver is accessed via a
well-known port, i.e. a port whose bit-pattern is a well-known
constant.)  [Do note that we require that the bit-pattern representing
a port be allowed to be transmitted between to processes without
the operating system needing to know that the bit-pattern represents
a port.  This means that accessing the nameserver is not required in
order to use a port.]

For groups, we have thought about extending the concept of a port to
an array-port.  The simple implementation of this allows each process
in a group to create a port.  These ports are all sent to a central
location which creates an array of ports and broadcasts the array to
all ports in the array.  The complex memory efficient implementation
may require processes of a group to be created in a special fashion.
Basically, it allows the address of a port for a specific process in a
group to be easily computed by another process given the port of the
first process in the group and the index of the target process in the
group.

-- Chuck