Subject: new draft of point to point section

From: "Marc Snir" <[email-masked]>
Date: Wed, 14 Apr 93 18:19:16 EDT

Just went out.  Comments, corrections are welcome.  I lost some of my notes
from the last meeting, so that I may have omitted some changes that were
agreed there.   Please draw my attention to such omissions, if any.
Hopefully, by next meeting, you will have this draft with full C/F syntactic
sugar, courtesy of Berryman and Geist.

A few points to notice:

1.  There are two new object creation functions (for comm objects and buffer
descriptor objects), rather than the generic function in the previous draft.

2.  Block/contiguous messages are typed.

3.  We have a secure send/receive now (I am not happy about the later).

4.  We have probe and cancel.

5.  We need to think carefully about object freeing (the decision last meeting
was to have "lazy" object freeing, but this is a problem with objects that
can have multiple references, like buffer descriptors).

6.  I clarified the issues of type/representation matching and conversion, and
added some pointers for a future discussion on interlanguage communication.

---

From: L J Clarke <[email-masked]>
Date: Thu, 15 Apr 93 11:41:58 BST

Dear mpi-pt2pt colleagues

First thanks to Marc for getting the new draft out so soon.

I had a quick read just now, and wanted to make a small number of
comments/suggestions/questions. 

STANDARD and SECURE modes
-------------------------

1) We were using the term REGULAR, but now see STANDARD.  Why? It seems
like a bad change, because it can be read to imply that the other modes
are somehow non-standard. 

2) The definitions seem to be incomplete or inaccurate.  Sould they not
say something more like:

READY
The send may start only if a matching receive has started. The send may
complete when the user buffer is available for reuse.

REGULAR
The send may start whether or not a matching receive has started.  The
send may complete when the user buffer is available for reuse.

SECURE
The send may start whether or not a matching receive has started.  The
send may complete when the user buffer is available for reuse and a
matching receive has started.

SECURE Receive
--------------

Marc includes some discussion of communication protocols.  I promised to
think more on this and return some better discussion.  We (myself and
the implementors of our system) talked long on the subject of mixing
SECURE and REGULAR communication modes over the last couple of days, and
optimisations of the modes.  I will write up this discusssion and send
it out if there is seen to be enough interest. 

The conclusions were:

a) The optimisation for SECURE communication mode which I was thinking
about when I asked for SECURE receive is also an optimisation for
REGULAR communication mode (whether the optimisations which I was
thinking of appear is a quality of implementation issue);

b) There is no difficulty mixing SECURE and REGULAR communication modes,
and little to be gained from the effort of not mixing them;

c) The SECURE Receive procedure is redundant!

I suggest that the SECURE receive is deleted. 

EPHEMERAL
---------

What does inclusion of EPHEMERAL communication handles really buy? They
can be used in non-blocking communications to avoid having to do a FREE,
which might mean one less transition from user space to system space. 
This is an optimisation for non-blocking operations.  Is this all? If
so, is it worth having them for that purpose?

WAIT_ANY
--------

There was some discussion at the meeting about fairness and WAIT_ANY. 
Marc reflects this with a discussion on Page 21 of the draft. 

We (at EPCC) would prefer that WAIT_ANY were fair, or at least that it
can be used fairly.  There seems to be some concern about implementing
WAIT_ANY to be fair. 

The rotating priority mechanism which Jim suggested is sufficient to
allow WAIT_ANY to be used fairly, and was common practice for occam
programmers of transputers.

Best Wishes
Lyndon

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