From whitlock@tle.ENET.dec.com Wed May 22 22:52:07 1996 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA22923 for ; Wed, 22 May 1996 22:52:00 +0200 Received: from us2rmc.zko.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA29231; Wed, 22 May 1996 16:42:33 -0400 (EDT) Received: from tle.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA28220; Wed, 22 May 96 16:27:55 -0400 Message-Id: <9605222027.AA28220@us2rmc.zko.dec.com> Received: from tle.enet; by us2rmc.enet; Wed, 22 May 96 16:38:28 EDT Date: Wed, 22 May 96 16:38:28 EDT From: Stan Whitlock DTN 381-2011 ZKO2-3/N30 To: sc22wg5@dkuug.dk, whitlock@tle.ENET.dec.com Apparently-To: sc22wg5@dkuug.dk Subject: X3J3 work in progress on asynch I/O Dear WG5 members: X3J3 has worked on the specifications of Asynchronous I/O at its past two meetings, working off the WG5 Fortran 2000 requirement specified at the November-1995 San Diego meeting. The attached paper is work in progress on this topic. I am sending it out to the WG5 distribution as requested by X3J3 for your information. Thanks /Stan -------------------------------------------------------------------------------- To: X3J3 X3J3/96-040r1 From: /jor (bleikamp) page 1 of 2 Subject: ASYNC I/O : Requirements for F2000 Background: We hope that WG5 and the Fortran community will have an opportunity to review and comment on these requirements before the "standardese" is developed for Fortran 2000. At meeting 136, X3J3 discussed async i/o, and took a number of straw votes, trying to establish a consensus about the various tradeoffs between user flexibility, implementation cost, and expected efficiency of the resulting implementations. These requirements are the outcome of that discussion. In general, X3J3 decided that more functionality was desirable, at the expense of extra memory allocations and memory copies. X3J3 assumes (and hopes) that appropriate cases will be substanially optimized, eliminating unnecessary temporary allocations and memory to memory copies when possible. The senario supported by existing practice, 1) Contiguous memory block (such as ONE named variable), using 2) Unformatted sequential I/O will hopefully be optimized by most vendors, and other senarios will likely incur additional overhead. There were other high level requirements which were generally accepted: - must be possible to be standard conforming on a processor/OS which does not support async i/o - must be readily implementable on a wide variety of OS's while achieving some level of asynchronous i/o - should use existing OPEN, READ, and WRITE statements, may add a new statement for WAITing for I/O completion - the user is prohibited from referencing the I/O list items until the I/O is complete (i.e. the WAIT statement was executed). X3J3/96-040 Requirements: page 2 of 2 - The user will request ASYNC I/O via the OPEN statement. All I/O to that unit may be performed asynchronously. - The READ and WRITE statements will be used, rather than some new intrinsic routine or BUFFERIN/OUT. - After executing a READ/WRITE on a unit OPENed for async i/o, the user shall WAIT for completion of the I/O before referencing the storage units referenced by the list items in the READ/WRITE. If the I/O request was a WRITE, the storage units can be referenced, but not defined. If the I/O request is a READ, the storage units may not be referenced or defined. - The mechanism used to WAIT for I/O completion will be a new statement or a subprogram call. The syntax to either WAIT for completion, or to inquire about the completion status (without waiting), will be provided. Note that an implementation is free to always WAIT for completion even when the user inquires about the status. This allows OS's which can only wait for completion to easily support async i/o. - The READ/WRITE statements will optionally return some sort of "handle", which uniquely identifies a particular I/O request. The WAIT mechanism will allow WAITing for a particular request via the "handle", AND, alternatively, allow WAITing for all requests for a user specified unit to complete, without specify any "handles". - The user may issue multiple I/O requests on a single or many units, without waiting for any of the previously issued requests to finish. An implementation might wait for a previously issued request on a unit to finish before proceeding. - An OPEN statement which specifies async i/o may open a file for either FORMATTED or UNFORMATTED I/O, and for either SEQUENTIAL or DIRECT ACCESS I/O. Note that formatted I/O potentially reads/writes several records, and is less likely to be optimized by all implementations. This is particularily true for list directed and namelist i/o. Note that for DIRECT ACCESS I/O, the "seek" will probably be done synchronously, and only the read/write will likely be done asynchronously. - Non-advancing I/O is prohibited on a unit opened for async i/o. - The READ/WRITE statements may have any valid list items. We considered restricting the I/O list items to ONE contiguous object, to ensure that the library would not have to allocate a temporary, and would not have to copy the I/O list to/from the temporary; however, X3J3 decided the enhanced functionality was worth the extra overhead. end of requirements