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: [email protected] Tel.: +44 1223 334761 Fax: +44 1223 334679

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120