[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