Subject: Asynchronous I/O

From: [email-masked]
Date: Thu, 12 May 94 08:31:56 -0400

I agree with Chuck's goals for an i/o requirements document.  I would
explicitly include his tag line ("Slipping in some reasons that
standard Fortran I/O statements are not sufficient would also be a good
idea.") as a part of his item 0.  Presumably a part of the "parallel
I/O problem" is that there are things that real users need to do that
can not be done (or are difficult or awkward to do) with existing
constructs.  (I know - my Turing machine is just as powerful as your
Turing machine, but it might be easier to use.)

I think there is a requirement for asynchronous i/o, but...

1. Just because a Fortran i/o statement is synchronous in its
definition, there is no prohibition against a compiler using code
motion, etc. to move all or part of the i/o to more convenient
locations in the program.  So even if the programmer doen't directly
have a language facility, the compiler can arrange to start the i/o
early, and then later wait for its completion.

2. The "asynchronous i/o" question seem to have two parts:  surface
syntax plus user semantics, and underlying mechanism.  It might be
worthwhile to add a requirement to the tasking group that their model
allow for the effect of asynchronous i/o such as start a task
containing "ordinary" Fortran i/o, synchronizing appropriately, and
making the results available.  A second issue, for the i/o group, might
then be whether any syntactic sugaring would be a user benefit or an
aid to the compiler in identifying a particular cliche for
optimization.  For example, FORALL is really just a sugaring of a
cliched use of DO loops with !HPF$INDEPENDENT, but it sure makes life
easier for the programmer and the compiler.

-David