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

[Bill Long]

N.M. Maclaren wrote:
> On Jan 23 2009, Bill Long wrote:
>>
>> 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.
>
> Agreed.
>
>> Having it on the corresponding dummy probably solves it as well.
>
> What corresponding dummy?  There may not BE one!

If there is one, it should work.  However, you are right that the 
general solution has to rely on having the asynchronous attribute in the 
caller.  (Which probably means a code modification for the user.)

>
>> 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.
>
> That is correct.  However, to make arbitrary broken programs work is
> beyond any mortal's ability!  The best that we can hope for is to 
> minimise
> the amount of rewriting needed.
>
>> 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.
>
> Neither of those solutions will work.  Sorry.
>
> Consider the situation where procedure Fred allocates a buffer, and then
> passes it down through two call chains:  
> Fred->Joe->Bert->Alf->MPI_Isend and
> Fred->Pete->Nick->Greg->MPI_Wait.  The buffer is then used in Greg.  The
> requirement is that neither of the call chains performs a 
> copy-in/copy-out
> at any stage.  It is perfectly legal to pass a non-contiguous section to
> an assumed size dummy (which is then contiguous); it doesn't matter 
> WHAT the
> interface to MPI_Isend is - that assumed size array is a copy of the 
> buffer
> that was allocated in Fred.
>
> The point is that the above problem has ALREADY been addressed for 
> Fortran
> asynchronous I/O.  If the politics are such that some vendors will refuse
> to accept that solution for genuinely asynchronous transfers, then we 
> have
> a big problem.  But, make no mistake, it's political and not technical.
>

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.  Fixing it in 
Fortran - making the dummy assumed-shape - is easy.  That's equivalent 
to the second option above.  The alternative is to avoid the "If..." 
part at the beginning of the constraints, which is the first option 
above.  I don't see any other options.  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.

Cheers,
Bill

-- 
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