(j3.2006) Comment on Fortran WG5 ballot N1846

[Van Snyder]

> />/ On Tue, 2011-04-19 at 15:27 -0700, Dan Nagle wrote:
> /
>   
>>> / This returns to the fundamental point that the processor knows all
>>>       
> />>/ regarding Fortran asynchronous i/o, but nothing of external libraries,
> />>/ whether or not said libraries are considered communications.
> />/ 
> />/ This is a red herring.
> /
> Hardly.
>
> Consider an implementation of Fortran asynch i/o such as the following:
>
> For writes:
>
> 1. At the asynch write statement, allocate a buffer large enough
>    to hold the i/o list, copy the i/o list items into the buffer,
>    and un-map the buffer from the virtual address space of the program.
>
> 2. Signal an external i/o processor to operate on the buffer,
>    perhaps using a DMA port.
>
> 3. Continue execution of the Fortran program.
>
> 4. At the wait statement, wait for the i/o processor to signal done
>    and deallocate the buffer.
>
> For reads:
>
> 1. At the asynch read statement, allocate a buffer large enough to contain
>    the i/o list, and un-map it from the virtual address space of the program.
>
> 2. Signal an external i/o processor to operate on the buffer,
>    perhaps using a DMA port.
>
> 3. Continue execution of the Fortran program.
>
> 4. At the wait statement, wait for the i/o processor to signal done,
>    re-map the buffer into the virtual address space of the program,
>    copy the buffer into the i/o list items, and deallocate the buffer.
>
> The i/o list items need no special handling during the time between
> the transfer statement and the wait statement.  Indeed, the actual transfer
> is done via an external processor accessing memory that is un-mapped
> from the program altogether!
>
> An arbitrary external library may not have access to the vendor's API,
> or the authors may simply have chosen not to use it (for lack of documentation,
> portability, or any other reason).
>   

This is all true, but is irrelevant to the fact that in the program

asynchronous X
external A, B
call A ( X )
call B
print *, X
end

the processor can't know if or how X is asynchronous.  If it provides 
asynchronous I/O, it has to respect the ASYNCHRONOUS attribute, no 
matter whether or how the "asynchronous" happens in A.

> The red herring is how many levels of call are involved.
>
>