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

[Rolf Rabenseifner]

Van and all Forum members,

Why not including buf into the argument list of MPI_Wait?

This was discussed already years ago:
 - In the split collective routines, we did this already in the 
   original definition.
 - MPI_Wait is part of a set of routines with
   all having an array of request handles, i.e.,
   a set of such invisible buffers.
   For those routines, such one additional argument 
   would not work.
 - You are right that it would work exactly for MPI_Wait and MPI_Test
   and if it is wanted by the MPI Forum,
   I can add two new Fortran routines
     MPI_Wait_f_sync_reg(buf,rq,ierror)
     MPI_Test_f_sync_reg(buf,rq,flag,ierror)
 - The question is, whether this duplication is necessary,
   because the problem can be solved with different methods,
   e.g., having buf as a module variable. 
   In this case the additional overhead for producing
   the dope-vector for buf is not needed,
   i.e., the existing MPI_Wait is the more efficient one. 

Comments from other members are highly appreciated.

Best regards
Rolf

----- Original Message -----
> From: "Van Snyder" <Van.Snyder at jpl.nasa.gov>
> To: interop-tr at j3-fortran.org
> Cc: "Jeff Squyres" <jsquyres at cisco.com>, "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>, "Rolf
> Rabenseifner" <rabenseifner at hlrs.de>
> Sent: Tuesday, April 19, 2011 10:35:53 PM
> Subject: Re: [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
> 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".

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)