(j3.2006) (SC22WG5.3920) [MPI3 Fortran] (SC22WG5.3917) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers

Van Snyder Van.Snyder
Fri Jan 23 18:32:23 EST 2009


On Fri, 2009-01-23 at 15:24 -0800, Bill Long wrote:
> 
> Van Snyder wrote:
> > On Fri, 2009-01-23 at 12:44 -0800, Bill Long wrote:
> >
> >
> >> The problem is solved for asynchronous I/O in Fortran by exactly the
> >> same means.  The solution relies on C1239 and C1240 [299:12-19] in
> >> 09-007.  If you violate either of these constraints, your program will
> >> be rejected by the compiler and you have to fix it....  If we plan to
> >> base a solution on asynchronous (or volatile) for MPI, then the
> >> solution is exactly the same as for asynchronous I/O in Fortran.
> >>
> >
> > Since solutions exist for asynchronous Fortran I/O, which is
> > indistinguishable from MPI hiding in an external procedure, why are we
> > having this conversation?
> >
> > Just write an extra layer to get at MPI_wait, having an assumed-shape
> > buffer dummy argument with the ASYNCHRONOUS attribute and without the
> > CONTIGUOUS attribute.  Since the buffer dummy won't be referenced, make
> > the procedure external, or better yet, write it in C, so a clever
> > optimizer won't inline it, notice the buffer isn't used, and then move
> > accesses to the buffer across the remaining reference to MPI_wait, which
> > is the present problem.
> >
> >
> 
> The copy-in/copy-out problem does not affect MPI_wait.  There's no
> argument to copy anyway.  Copy-in/copy-out is a serious problem for the
> earlier call to MPI_Isend, etc. where you do not want the copy temp
> being the buffer MPI sees, since it will get deleted when the call
> returns (which is before MPI is done with it.)   This continues with any
> subsequent call to other routines that have the buffer as the argument,
> because a copy-out runs the risk of overwriting the buffer with the
> wrong values.

The copy-in/copy-out problem appears to be pretty simple:  Define the
buffer dummy argument of MPI_Isend to be ASYNCHRONOUS and assumed size.
Then if somebody hands it an assumed-shape or pointer buffer that's not
contiguous, the code falls afoul of C1239 or C1240.  If the user's data
isn't contiguous, it's his responsibility to do the copying at the right
time.

I don't see the need for changes in the standard, either for the
copy-in/copy-out problem, or the code motion problem.  Just define the
MPI interface properly.





More information about the J3 mailing list