(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