Subject: buffering proposal to mpi-envir

From: [email-masked]
Date: Thu, 8 Apr 93 12:11:37 PDT

Al Geist writes:

> We will not serve our purpose if we declare every program
> that requires buffering to be unsafe.
> The vast majority of message-passing programs are written now
> assuming some buffering.
> Many programs suffer a big performance hit if they have to be
> written with synchronous communication exclusivily. (to be "safe")

I agree, and I have previously informally proposed a way to get
around this problem in a system-independent fashion.

This seems like a point-to-point issue, but the minutes of the
Feb.17-19 meeting say that it was deferred to the Environment
subcommittee.

So, I hereby officially offer this proposal to the Environment
subcommittee, with cross-posting to both groups.

PROPOSAL TO SUPPORT MPI MESSAGE BUFFERING IN USER-PROVIDED SPACE

1. INTERFACE

   An application program can optionally provide buffer space
   for MPI's use:

    e.g.   MPI_USER_PROVIDES_BUFFER (len,buffer)
   
    where   IN len           is the length of 'buffer', in bytes.
            OUT buffer       is a scratch array of len bytes for MPI's
                             use in buffering messages

2. FUNCTIONALITY

   If the above routine is called, then for subsequent sends, MPI
   must *act as if* message data is being buffered by the sender.

   That is, user-provided buffer space may be consumed by outgoing 
   messages, but not by incoming ones.
        
3. POSSIBLE IMPLEMENTATION

   One approach is for MPI to simply transform all blocking sends
   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)

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

4. DISCUSSION

   The intended usage is that an application will provide buffer
   space once, immediately after MPI initialization.  This is a
   minimalist proposal.  An application may not be able to
   compute tight bounds on how much buffer space is actually 
   required, but at least the proposed interface provides a single
   point-of-modification to aid in porting.

   No mechanism is proposed for canceling MPI access to the
   user-provided buffer.  

   No mechanism is proposed to support multiple buffer spaces,
   although this might be convenient for some libraries.

   Allowing user-provided buffer space to be bound to a particular
   context (per Lyndon's recent suggestion regarding 'secure'
   communications) might meet both of these needs, but further study
   of that extension would be required.

--Rik Littlefield

----------------------------------------------------------------------
[email-masked] (alias 'd39135')   Rik Littlefield
Tel: 509-375-3927                         Pacific Northwest Lab, MS K1-87
Fax: 509-375-6631                         P.O.Box 999, Richland, WA  99352