This section defines a mechanism for performing Asynchronous I/O from an HPF or Fortran program. These are presented as changes to the Fortran 95 proposed draft standard, X3J3/96-007r1. This extension is a subset of the proposed X3J3 Asynchronous I/O extension, paper X3J3/96-158r2. Briefly, this extension allows direct unformatted data transfers to be performed asynchronously with program execution. The WAIT statement can be used to wait for the data transfers to complete. The INQUIRE statement can be used to determine if the data transfers are complete.
To section 9.3.4, rule R905 connect-spec, add
or ASYNCHRONOUS
Add a new section after 9.3.4.10, entitled ``ASYNCHRONOUS specifier in the OPEN statement'', containing the following paragraphs:
If the ASYNCHRONOUS specifier is specified for a unit in an OPEN statement, then READ and WRITE statements for that unit may include the ASYNCHRONOUS specifier in the control information list.The presence of an ASYNCHRONOUS specifier in a READ or WRITE statement permits (but does not require) a processor to perform the data transfer asynchronously. The WAIT statement is used to wait for or inquire as to the status of asynchronous input/output operations.
To section 9.4.1, rule R912 io-control-spec, add
or ID = scalar-default-int-variable
or ASYNCHRONOUS
and also add the constraints
- If either an ASYNCHRONOUS or an ID= specifier is present, then both shall be present.
- If an ASYNCHRONOUS specifier is present, the REC= specifier shall appear, a format shall not appear, and a namelist-group-name shall not appear.
- If an ASYNCHRONOUS specifier is present, then no function reference may appear in an expression anywhere in the data transfer statement.
At the end of section 9.4.1, add the following paragraphs:
The addition of the ID= specifier results in the initiation of an asynchronous data transfer. Execution of the data transfer statement shall be eventually followed by execution of a WAIT statement specifying the same ID value that was returned to the ID variable in a data transfer statement. This WAIT statement is called the matching WAIT statement. Note that asynchronous data transfer shall be direct and unformatted.The matching WAIT statement shall be executed in the same instance of the same subprogram in which the asynchronous data transfer statement was executed.
- Advice to implementors.The above restriction is to prevent the compiler from performing code motion optimizations across WAIT statements. Any operations involving variables listed in asynchronous input/output lists must be performed after the matching WAIT statement is executed. (End of advice to implementors.)
No ASYNCHRONOUS specifier nor any ID= specifier shall be specified if the io-unit was not opened with the ASYNCHRONOUS specifier.
In section 9.4.1, in the fourth and fifth paragraphs after the constraints, change both instances of ``IOSTAT= or a SIZE='' to ``IOSTAT=, SIZE=, or an ID=''.
Insert the following text at the end of section 9.4.3 before the final paragraph:
For an asynchronous data transfer, errors may occur either during execution of the data transfer statement or during subsequent data transfer. If these errors occur during the data transfer statement and do not result in termination of the program, then they will be detectable using ERR= and IOSTAT= specifiers in the data transfer statement. If these error conditions occur during subsequent data transfer and do not result in termination of the program, then they will be detectable using ERR= and IOSTAT= specifiers in the matching WAIT statement.
In the paragraph at the end of section 9.4.3, change the first occurrence of ``execution'' to read ``execution or subsequent data transfer.''
To section 9.4.4, add the following paragraphs:
For asynchronous data transfers steps 1-8 correspond to both the asynchronous data transfer statement and the matching WAIT statement. Steps 4-7 may occur asynchronously with program execution. If an implementation does not support asynchronous data transfers then steps 1-8 may be performed by the asynchronous data transfer statement. The matching WAIT statement shall still be executed, the only effect being to return status information.Any variable that appears as an input-item or output-item in an asynchronous data transfer statement, or that is associated with such a variable, shall not be referenced, become defined, or become undefined until the execution of the matching WAIT statement. However, it is allowed for a pointer to become associated with such a variable.
Multiple outstanding asynchronous data transfer operations (READ or WRITE) are allowed; however, no two WRITE operations may use the same unit and record number without an intervening WAIT.
READ(10,ID=IDNUM,REC=10) I,A(I)
is conforming and has the same input behavior as a synchronous READ. (End of advice to users.)
In section 9, change ``and INQUIRE statements'' to ``, INQUIRE, and WAIT statements''.
In section 9.6.1.14, add the following sentence as the last sentence of the paragraph:
If there are outstanding data transfer operations for the specified unit, the value assigned to the NEXTREC= specifier is computed as if all the outstanding data transfers had already completed, in the order in which they were issued.
To section 9.6.1, rule R924 inquire-spec, add
or ID = scalar-default-int-variable
or PENDING = scalar-default-logical-variable
and also add the constraints
- The ID= and PENDING= specifiers shall not appear in an INQUIRE statement if the FILE= specifier is present.
- If either an ID= specifier or a PENDING= specifier is present, then both shall be present.
Add a new section after 9.6.1.22, entitled ``ID= and PENDING= specifiers in the INQUIRE statement'', containing the following paragraph:
If an ID= specifier is present in an INQUIRE statement, then the variable specified in the PENDING= specifier is assigned the value true if the data transfer identified by the ID= specifier for the specified unit has not yet completed. In all other cases, the variable specified in the PENDING= specifier is set to false.