[Mpi-forum] Comment on Fortran WG5 ballot N1846

[Rolf Rabenseifner]

John and Bill,

thank you for your clarifications.

"For asynchronous output, a pending input/output storage sequence affector (9.6.2.5) shall not be redefined,
become undefined, or have its pointer association status changed.
For asynchronous input, a pending input/output storage sequence affector shall not be referenced, become defined,
become undefined, become associated with a dummy argument that has the VALUE attribute, or have its pointer
association status changed."

seems to be the key.
As long as one word of an array is part of pending a async input or output, the whole array must not be 
referenced or redefined.

Therefore, my example does not work in combination with the definition
of a pending input/output storage sequence affector.

I'll think about the implication on MPI nonblocking.

Best regards
Rolf 

----- Original Message -----
> From: "John Reid" <John.Reid at stfc.ac.uk>
> To: longb at cray.com, "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "Craig Rasmussen" <rasmussn at lanl.gov>, "Reinhold Bader" <reinhold.bader at lrz.de>, "N.M. Maclaren" <nmm1 at cam.ac.uk>,
> "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Tuesday, April 12, 2011 11:42:50 AM
> Subject: Re: [Mpi-forum] Comment on Fortran WG5 ballot N1846
> Bill Long wrote:
> > Hi Rolf,
> >
> > Sorry for not getting back sooner. Embedded comments below.
> >
> > On 4/3/11 12:53 PM, Rolf Rabenseifner wrote:
> >> Bill, John, and all together,
> >>
> >> I want to explain the background of our comment from the MPI Forum,
> >> why we expect that ASYNCHRONOUS and VOLATILE are quite different
> >> und why we want to extent ASYNCHRONOUS to MPI nonblocking accesses
> >> ***without*** giving ASYNCHRONOUS a semantics similar to VOLATILE.
> 
> I would like to add a few words to what Bill has said. He quoted these
> words
> from the standard:
> 
> "A pending input/output storage sequence affector is a variable of
> which any
> part is associated with a storage unit in a pending input/output
> storage sequence."
> 
> and
> 
> "For asynchronous output, a pending input/output storage sequence
> affector (9.6.2.5) shall not be redefined, become undefined, or have
> its pointer association status changed."
> 
> I think this means that the code
> 
> USE mpi_f08
> REAL, ASYNCHRONOUS :: buf(100,100)
> ! communicating a boundary of the array:
> CALL MPI_Irecv(buf(1,1:100),...req,...)
> DO j=1,100
> DO i=2,100
> buf(i,j)=.... ! work only on the inner area
> END DO
> END DO
> CALL MPI_Wait(req,...)
> 
> would not conform to the standard if we extend it to treat
> non-blocking MPI
> calls and matching waits in the same way as asynchronous I/O. This is
> because
> buf is an object and buf(1,1:100) is a part of it. To make this work
> needs a
> separate array for buf(1,1:100).
> 
> Without a change to the standard, the compiler can assume that any
> asynchronous
> I/O will have completed within MPI_Irecv since other parts of buf are
> used
> immediately afterwards. It might therefore copy the whole of buf to a
> GPU and
> copy it back when the work is done.
> 
> The other comment I would like to make is that I would like to see the
> TR
> include an example of non-blocking MPI showing the use of ASYNCHRONUOS
> or
> VOLATILE or whatever else we recommend for this case. It would be
> great to have
> you help us with this.
> 
> Cheers,
> 
> John.

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