[MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846

[Jeff Squyres]

There's a few reasons we shouldn't add the buffer argument to MPI_WAIT (and friends) -- this has been discussed and discarded many times already.

1. The signature of MPI_WAIT (and friends) has been around for 18 years and there's lots of codes using it.  It would be fairly disruptive to change it.

This may be a weak argument; the other 2 are stronger.

2. The request passed to MPI_WAIT may not have a buffer associated with it.  MPI has lots of types of requests, not just non-blocking point-to-point communication requests.

3. Other flavors of MPI_WAIT take arrays of requests (e.g., MPI_WAITALL). We'd have to pass an array of buffers corresponding to the array of requests, which would just be plain icky (would you have to have an array of fortran pointers to refer to all the requisite buffers?).




On Apr 19, 2011, at 5:40 PM, Rasmussen, Craig E wrote:

> I know we didn't want to change the API of MPI_Wait because scope of the call to MPI_Wait may not have access to buf.  However, your example does have access to buf so why not just overload MPI_Wait to take an additional argument:
> 
> 
>      CALL MPI_Wait(rq, buf1)
>      CALL MPI_Wait(rq, buf2)   ! from an MPI perspective this has no effect as the request has already been satisfied
> 
> Although this could be a little slower than a call to MPI_F_SYNC_REG as the library has to look at the rq argument.
> 
> -craig
> 
> 
> On Apr 19, 2011, at 2:35 PM, Van Snyder wrote:
> 
>> 
>> On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote:
>>> With
>>> CALL MPI_Irecv(buf, rq)
>>> CALL MPI_Wait(rq)
>>> CALL MPI_F_SYNC_REG(buf)
>>> xnew=buf
>>> 
>>> 
>>> The content of MPI_F_SYNC_REG is outside the scope of the
>>> Fortran optimization.
>>> I do not see that the compiler is allowed to move 
>>> "xnew=buf" before the MPI_Wait statement because
>>> "MPI_F_SYNC_REG(buf)" may have modified the content of buf.
>>> 
>>> Therefore the problem is solved.
>>> 
>>> Correct?
>>> 
>>> If not, please can you show a detailed code, how 
>>> such a compiled code could work and in xnew is at the end
>>> ***not*** the value that was stored in buf by MPI_Wait.
>> 
>> If this works, why not change the Fortran -> MPI interface for MPI_Wait
>> to include "buf" instead of attaching the TARGET attribute to "buf" and
>> hoping the processor will guess that implies that a pointer to "buf"
>> might be hiding in "rq"?  After all, the processor can see "rq" and its
>> type (which might actually be TYPE(*)?), so it might (reasonably)
>> conclude from its analysis that "rq" doesn't contain any pointers to
>> "buf".
>> 
>> 
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/