(j3.2006) 09-211 is unnecessary

Jim Xia jimxia
Thu Apr 30 15:50:21 EDT 2009


j3-bounces at j3-fortran.org wrote on 04/30/2009 03:29:14 PM:

> 
> Paper 09-211 proposes to add a construct
> 
> ASYNCHRONOUS buffer
> ...
> ASYNC_BLOCK (buffer)
>     CALL MPI_IRecv(buffer,...,request,...) ! request receive into buffer
>     ...! do other work while the buffer transfer in progress
>     CALL MPI_Wait(request,...)        ! wait for communication to finish
>     ...
>     call foo(buffer)                       ! do work with buffer
> END ASYNC_BLOCK
> ...
> 
> This is unnecessary now that we have the BLOCK construct.  Instead the
> program should use
> 
> BLOCK
>     ASYNCHRONOUS :: buffer
>     CALL MPI_IRecv(buffer,...,request,...) ! request receive into buffer
>     ...! do other work while the buffer transfer in progress
>     CALL MPI_Wait(request,...)        ! wait for communication to finish
>     ...
>     call foo(buffer)                       ! do work with buffer
> END BLOCK


They are different.  What if a user wants to use Fortran's async IO in the 
block construct instead of MPI_wait calls?  There is no way to distinguish 
the two cases.



> 
> This is unrelated to MPI.  The potential for the problem described in
> 09-211 to occur is also present in
> 
>     CALL A(buffer,...,request,...) ! request READ into buffer
>     ...! do other work while the buffer transfer in progress
>     CALL B(request,...)        ! wait for READ to finish
>     ...
>     call foo(buffer)                       ! do work with buffer
> 
> if A were to execute an asynchronous READ statement and B were to
> execute a WAIT statement.
> 
> The solution is the same for the Fortran problem and the MPI problem:
> The compiler can't move anything involving a variable with the
> ASYNCHRONOUS attribute across a procedure reference, and it it has the
> POINTER or TARGET attribute it also can't move anything involving
> pointers with the same type and kind (and just about any rank if it's
> rank 1 or contiguous) across a procedure reference, and if it's a common
> variable or a public module variable it can't reorder procedure
> references, and it can't reorder references to internal procedures,
> and ....

Then you need to tell compiler what your intention is.  Assuming compiler 
will get it right by simply using TARGET, POINTER or ASYNCHRONOUS 
attributes is a big mistake.

Cheers,

Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM

http://www.ibm.com/software/awdtools/fortran/xlfortran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20090430/aa37553b/attachment.html 



More information about the J3 mailing list