Subject: buffering in point to point

From: "Marc Snir ((914) 945-3204 (862)" <[email-masked]>
Date: Sun, 20 Feb 94 14:54:53 EST

Among the comments we got there where many that insisted that buffering is very
important, and some that wanted CMMD style communication.  In the time honored
MPI tradition, we should consider appeasing both by providing additional
functions.

A possible proposal is outlined below:
Add a fourth mode in pt2pt communication.

Thus, we shall have,  for blocking sends

1.  Synchronous:  returns when a matching receive has started.  The intended
implementation is that no buffering is done.  Completion
of such send is nonlocal.
> [No buffering, non-local, always succeeds, can deadlock]

2.  Asynchronous: returns irrespective of the state of the receiver.  If no
receive is posted, then the message has to be buffered.  Completion of such
send is local.  If the operation cannot complete (no buffer, no receiver) then
an error occurs.
> [Buffering (if necessary), local, fails sometimes, cannot deadlock]

3. Standard:  I.e., implementation-dependent.  The message may be buffered,
thus allowing the operation to complete, or the send may block until a matching
receive occurs.  Completion is nonlocal.  The operation never fails, but lack
of buffer space may cause dealocks.
> [Buffering (if necessary), non-local, always succeeds, can deadlock]
>
> "3" is either...
>	"1"
>	or "2" with retry (should we discuss semantics for retrying/timeouts?)
>

4.  Ready:  a variant of (1) and/or (2), where the user promises that a
receive is already posted -- thus, no buffering is needed.
> [No buffering, non-local, fails if receive not posted, cannot deadlock]
>
> "4" is "3" + the promise of the user to have a receive posted.
>
This extends, as usual to nonblocking sends:

(1) a WAIT for a synchronous immediate send blocks until a receive
has cleared the send buffer.
(2) a WAIT for an asynchronous immediate send returns after the message is
received or buffered, and causes an error if neither can be done.
(3) a WAIT for a standard send can block if there is no posted receive or
available buffer space, waiting for either to become available, due to
other processes' acitivity.
(4) a WAIT for a ready send returns after the receive has cleared the
send buffer.

This means 3 more functions (blocking, immediate, persistent send).
> Please explain further.
Comments?

----- End Included Message -----