[MPI3 Fortran] [Fwd: Was ASYNCHRONOUS..., New: ACCESSES ( ) suffix

Bill Long longb at cray.com
Wed Sep 10 13:26:42 CDT 2008


>
> It seems this is more specifically a case like the following:
>
> ! Code region A
>
> Call MPI_xxx (buffer, ...) ! Async send or receive
>
> ! Code region B
>
> Call MPI_wait (...)  ! Wait until operations on buffer are complete
>
> ! Code region C
>
There seem to be two goals here.  One is to prevent definitions or 
references to the argument buffer from moving across the call to 
MPI_Wait.  The other is to avoid having the programmer change his 
current source code (by, for example, requiring that buffer be supplied 
as an argument to MPI_Wait).  The solution for the second goal is to 
"fix" the problem in an interface block.  There is a lot of focus on the 
interface block for MPI_xxx, even though that is not  where the real 
problem exists.  Would a more direct approach (requires new syntax) like 
this be better?

interface
    subroutine MPI_Wait ( ... )  accesses (MPI_ISend(buffer),  
MPI_IRecv(buffer) )
      ...
    end subroutine MPI_Wait
end interface

Fortran already has BIND and RESULT suffixes for procedure interfaces 
and definitions, so this would not be a major syntax change.  The new 
"accesses" suffix would have a list of  <proc-name> ( <dummy-arg-list> ) 
entries.  The procedures names shall have accessible interfaces and the 
dummy arguments listed shall be the same as dummy arguments of that 
procedure.   The message to the compiler (in this example) is that a 
Call to MPI_Wait may access the actual argument corresponding to the 
buffer dummy argument in any call to either MPI_ISend or MPI_IRecv that 
is visible.  This would explicitly suppress the undesired code motion.

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

            




More information about the mpiwg-fortran mailing list