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" <[email protected]> To: [email protected], "Rolf Rabenseifner" <[email protected]> Cc: "Craig Rasmussen" <[email protected]>, "Reinhold Bader" <[email protected]>, "N.M. Maclaren" <[email protected]>, "Main MPI Forum mailing list" <[email protected]> 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 [email protected] 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)