[MPI3 Fortran] MPI non-blocking transfers

[Bill Long]

Thanks to Jeff Squyres  for the clear MPI tutorial.


N.M. Maclaren wrote:
>
>
> Questions:
>
>    1) Most people seem to agree that the semantics of the buffers used
> for MPI non-blocking transfers and pending input/output storage
> affectors are essentially identical, with READ, WRITE and WAIT
> corresponding to MPI_Isend, MPI_IRecv and MPI_Wait (and variations).
>
> Do you agree with this and, if not, why not?

Almost the case.  One key difference is that a variable in the io list 
of an asynchronous read or write automatically acquires the asynchronous 
attribute, even if  it is not declared that way.  If we want a similar 
capability for the MPI case, then the attribute name would have to be 
different from ASYNCHRONOUS.  That is probably a good idea anyway to 
avoid undesirable interaction with  actual asynchronous variables in 
Fortran.  Having the buffer automatically acquire this new attribute is 
necessary if we want to avoid requiring changes to existing codes.


>
>
>    2) Most people seem to agree that a data attribute is essential, and
> a purely procedure-based solution will not work.
>
> Do you agree with this and, if not, why not?

The question hints at a common confusion.  There are TWO basic problems 
we are trying to address.

1)  Preventing code motion by the compiler across a call to an 
MPI_wait-like subroutine.  This is needed to avoid the possibility that 
user-coded modifications to the buffer (which is not present as an 
argument in the call) do not migrate to before the call.  A subroutine 
prefix keyword simply and completely solves this problem.  I recently 
sent out such a proposal, with the prefix spelled VOLATILE.  This 
solution has the desirable feature that no change to the user's source 
code is needed as long as they already have a 'use mpi' statement, or a 
compiler switch to cause the same effect.


2) Preventing modifications to the buffer between the call to the 
transfer initiation subroutine and the corresponding wait subroutine.  
These can come in two forms:  The user explicitly codes such 
modifications, which is the user's fault and not something we should try 
to solve.  I would note that, in Fortran, this can be not obvious to a 
novice programmer.  For example, if the buffer were locally declared as 
allocatable without the save attribute, it will be deallocated at the 
end of the subroutine.  If the wait routine is in a later-executed 
subroutine, this is a user error.  The other form is the one we need to 
worry about:  the internal generation of local temporary copies of the 
buffer by the compiler (so-called copy-in/copy-out for an actual 
argument).    Various solutions to this problem have been discussed, 
most centering on an attribute for dummy arguments or coding versions of 
the MPI routines that accept pass-by-descriptor rather than 
pass-by-address for the buffer argument.

>
>
>    3) It would be very easy to extend the wording of the ASYNCHRONOUS
> attribute etc. to allow for asynchronous I/O started and completed by a
> companion processor (including MPI, here).  It would also be very easy
> to add a new one (say, ASYNCH_EXTERNAL), with the same properties, but
> applying only to companion processor I/O.
>
> Do you think that adding a new attribute is desirable and, if so, why?

Adding a new attribute would be preferred to recycling ASYNCHRONOUS in 
that it avoids undesired interaction with actual asynchronous 
variables.  The drawback is that we will need to define the semantics 
for such variables in a Fortran program, though I think that is doable.

>
>
>    4) For Fortran asynchronous I/O, the processor obviously knows when
> an input/output storage affector becomes and ceases to be pending.  From
> the point of view of program correctness, this information is not
> needed, but it might be useful for implementors.  I proposed such a
> mechanism, but it seemed to confuse some people.
>
> Do you believe that there needs to be a standardised mechanism for the
> companion processor to inform the Fortran processor of such state
> changes and, in either case, why or why not?
>

The remaining problem is to prevent copy-in/copy-out.  That occurs only 
at a call site, so the status of the buffer between such points is not 
really relevant.


Cheers,
Bill


>
>
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120