(j3.2006) Comment on Fortran WG5 ballot N1846

[Dick Hendrickson]

On Wed, Apr 20, 2011 at 1:29 AM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

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

For this simple case, the processor knows all it needs to know.  At the
print statement, it knows for sure that X is not involved in an input-like
operation and doesn't care if it is in an output-like operation.  I think
that's true for any use of X anyplace in the program.  What the processor
can't do is move usage of X across things which might be involved with X
asynchronously.

Dick hendrickson



>
>  The red herring is how many levels of call are involved.
>>
>>
>>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20110420/08d7eb69/attachment-0001.html>