(j3.2006) 09-211 is unnecessary

Van Snyder Van.Snyder
Thu Apr 30 16:29:03 EDT 2009


On Thu, 2009-04-30 at 12:50 -0700, Jim Xia wrote:

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


And that is the way it ought to be, because they are not different.  If
the MPI_IRecv call and the MPI_Wait call are within other Fortran
procedures, e.g. in the subroutines A and B in the next example, the
problems are indistinguishable.


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


The compiler better get it right if you specify the ASYNCHRONOUS
attribute, or it isn't able to handle asynchronous I/O correctly.  It
has to get it right for asynchronous I/O, even if the I/O and WAIT occur
in subroutines.  There is no difference between this and MPI
asynchronous transfers.


> 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/b08fd044/attachment.html 



More information about the J3 mailing list