(j3.2006) (SC22WG5.3915) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers
Fri Jan 23 15:14:50 EST 2009
On Fri, 2009-01-23 at 11:39 -0800, Bill Long wrote:
> Van Snyder wrote:
> > On Fri, 2009-01-23 at 01:56 -0800, N.M. Maclaren wrote:
> >> In theory, but not in practice. Not merely is the identifier an integer
> >> value (and may be the result of arbitrarily complicated extraction), the
> >> WAIT statement may be inside an external procedure.
> > That's what the ASYNCHRONOUS attribute for arguments is supposed to
> > address.
> Since a WAIT statement could occur in a subprogram (at least ones the
> compiler does not know about, such as ones not intrinsic or inlined)
> then it is part of the required implementation that operations on a
> variable with the asynchronous attribute not be moved across such a
> call. Included in the class of calls that block code motion would be
> those to the MPI routines. Having the asynchronous attribute in the
> caller scope effectively solves the code motion problem. Having it on
> the corresponding dummy probably solves it as well.
> Jim pointed out that asynchronous may not be that useful in the end. I
> think this is an important point. As noted above, asynchronous can
> solve the code motion problem. It is not clear what you mean by "solve"
> in regard to the other main problem - copy-in/copy-out of actual
> arguments. What the asynchronous attribute will do is cause a program
> that would otherwise have to include copy-in/copy-out code at the call
> to the MPI_Ixxx routine to, instead, get a hard error at compile time
> based on a constraint violation. It does not make the program "work",
> which is probably somewhere on the user's agenda.
It sounds like this is a problem for asynchronous I/O, regardless of
whether it's done by I/O and WAIT statements hiding in external
procedures, or by MPI hiding in external procedures.
If ASYNCHRONOUS is defective, we need to repair it, without getting
distracted by worrying whether it's spelled MPI_ISEND or
ASYNCHRONOUS='YES' in an external procedure into which the processor
> To get a working
> program, there are two possible solutions that I see:
> 1) Require that the user always supply a contiguous actual argument
> corresponding to the buffer dummy (in which case it seems to make more
> sense for THAT to be the requirement on the user in the first place), or
> 2) Provide a Fortran interface than can handle non-contiguous sections
> by having assumed-shape corresponding dummies. This solution off-loads
> the bulk of the work to the MPI folks. But is does seem more robust.
> It would be useful to hear feedback from the MPI group on these
More information about the J3