Subject: Re: Buffering requirements

From: [email-masked] (Stephen R. Wheat)
Date: Mon, 8 Feb 93 08:36 MST

Jon asks:

>> Is there a way around this? If so, it seems like a great idea
>> to me. If not, is it going to be acceptable to the High Priests
>> to have this three-hop version?

This brings us back to the question of the "Ready Receiver".
That is, should one KNOW that a matched receive has already
been posted, then one should be able perform the send without
having to go through the heavy duty "RTS/CTS/Data" sequence.

One other point I would like to raise is that the phrase
"system buffering" implies an implementation where the
system provides the buffering rather than the application.

I believe that one could argue that "application buffering"
would be more portable, in that the application/library
would depend on more basic services, such as application
memory allocation to provide the buffering.

Stephen

---

From: [email-masked]
Date: Mon, 8 Feb 93 09:03:26 PST

Jon Flower says:

> I agree with Jim Cownie's comment that trying to figure out buffering
> requirements in an application is difficult for the receiver and hence
> the problems in creating REALLY reliable code with buffered systems.
> A potentially easier option is the one that Rik Littlefield mentioned - 
> buffering at the sender instead. For most applications it is MUCH 
> easier to compute how much is going to be sent than how much will 
> be received.
> 
> However, buffering at the sender seems to impose an implementation
> feature, i.e., that there be an intial message describing the actual
> transaction followed by a data request and finally the data itself.
> 

Let's see if I can remember what it was I proposed.  I think
it went like this:

1. Provide an MPI hook that an application could call to declare the
   maximum amount of data that might be sent to unready receivers.

2. Require that an application calling the hook also provide buffer
   space for that much data.

3. Require that if the hook is called, MPI then must *act as if* it
   were working in "sender-buffers" mode.

4. One possible implementation of this approach is for MPI to simply
   transform all blocking send calls into

      . copy data to (application-provided) buffer space
      . issue non-blocking send from the buffer copy
      . return to application

   and 

      . check completion on subsequent MPI call(s)

This implementation does not seem to impose any extra costs at the
protocol level.  In particular, if non-blocking send can be
accomplished without an "RTS/CTS/data" sequence, say by assuming some
amount of buffering at the receiver as in the Intel iPSC short-message
and DELTA protocols, then the sender-buffers implementation proposed
here should be able to do the same.

No doubt many optimizations within MPI are possible -- the proposal
just requires that MPI act as described here.

I am not sure how the sender-buffers declaration should look in order
to best support libraries.  One possibility would be to allow the
declarations to be nested, so that each library could declare its own
needs at the point where those needs are determined.  I'm not
convinced that this is much easier than just (re)coding the library to
use non-blocking sends directly, but it seems to fit with the basic
idea of portable support for non-blocking csend's.

--Rik Littlefield