Subject: hpff-core: ANSI X3J3 work in progress on asynch I/O

From: Stan Whitlock DTN 381-2011 ZKO2-3/N30 <[email-masked]>
Date: Wed, 8 May 96 16:03:31 EDT

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------
Mary,

My name is Stan Whitlock.  I represent DEC on X3J3 and am responsible for the
handling of Fortran 2000 requirements.  J3 discussed Asynch I/O at its Feb-96
meeting and produced the appended paper as work in progress.  I believe the
plan is to do more work on this topic next week at the May-96 meeting.

J3 is aware of HPFF's interest in this topic and its ultimate standardization.
As our work progresses, we will keep you informed.

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
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------