I have made most of the changes suggested, but have questions on a few:
> 220/33-41: A definition of what is a collective I/O call must be given
> here. i.e. it must be called by all processes that opened the file
> with a collective open call.
> Some rules about collective communication calls do not apply to I/O
> and must be mentioned here (or somewhere). For example, arguments to
> collective I/O calls need not be matching among processes: counts,
> datatypes, and offsets can be different for each process. Even the
> file view of each process may be different, except for shared file
> pointer routines.
The definition of collective is given in 10.6.4 Collective File
Operations. I have been thinking of removing *all* of section 10.4.1,
and moving the useful pieces to other sections (10.4.1 has become
somewhat out of date). I would move:
Move: "POSIX read() and write() are blocking, non-collective
operations, and use individual file pointers. The MPI
equivalents are MPI_READ and MPI_WRITE."
to 10.4.3 Data Access with Individual File Pointers intro
Move: "MPI_FILE_SYNC provides the only guarantee that data has
been written to "permananet" storage."
to the definition of MPI_FILE_SYNC in 10.6.1.
Move: "Explicit offset operations perform data access at the file
position given directly as an argument---no file pointer is
used nor updated. Note that this is not equivalent to an
atnomic seek-and-read or seek-and-write operatin in UNIX, as no
"seek" is issued."
to 10.4.2 Data Access with Explicit Offsets intro
Move: "Once a nonblocking data access operation is initiated, accessing
the local buffer of the operation, or using it as the source
or target of other communications, before the operation
completes is erroneous"
to 10.4.2 Data Access with Explicit Offsets IREAD_EXPLICIT and
IWRITE_EXPLICIT explanations
or to a new "10.1.2 Conventions" section (along with a bunch of other
stuff which is globally true, like 10.6.4 Collective File Operations).
Move the detailed semantics from 10.4.1 Coordination
to 10.4.2 under READ_EXPLICIT_ALL and WRITE_EXPLICIT_ALL
or to a new "10.1.2 Conventions" section.
> 221/29-30: We must be careful about what we say here. In MPI-1,
> MPI_Get_count returns the number of elements of type "datatype"
> that were received; "datatype" must be the same datatype used in
> the recv call. MPI_Get_elements returns the number of "basic"
> datatypes that were received. If we directly use the same for
> I/O, the number of "datatype" elements read or written can be
> obtained from MPI_Get_count. But the number of etypes can not
> necessarily be obtained from MPI_Get_elements, because etypes
> may not be basic datatypes. In other words, there may not be a
> way to directly extract from status the number of etypes read
> or written, unless we modify the meaning of MPI_Get_elements
> for the purpose of I/O. Whatever we decide, the sentence needs
> to be changed in every data access routine.
I agree that we must be careful. The current sentence is not incorrect,
although it does appear misleading. Since this appears in multiple
places, I would prefer deleting all references to it in the text,
and saying it once in an introductory paragraph. Perhaps in the
Data Access introduction (10.4.1) or in a new "10.1.2 Conventions"
section.
In either case, what text do you propose to make it more clear?
> 248/46 - 249/6: Can't MPI_SEQUENTIAL be used to indicate
> sequential access even to files that can be accessed randomly,
> eg. Unix files? I thought the intent was to allow this,
> so that such accesses can be optimized. In other words,
> MPI_SEQUENTIAL refers to sequential access, not necessarily
> a sequential file. Some files, of course, can only be accessed
> sequentially. For such files, is it erroneous if the user accesses
> them sequentially, but does not specify MPI_SEQUENTIAL in the
> open call? Clarification needed here and in MPI_Open.
Again this seems reasonable. Text?
====================
The following were not changed because I either did not understand
the correction, or was unsure it should be made.
> 229/4-11: Instead of advice to users, it should be a requirement
> that the file view must be identical on all processes for using
> shared file pointer routines.
It is a requirement---see the third bullet in the introductory
paragraphs. The advice is additional explanatory text.
> 244/10-11: What does "count contiguous data items of type etype"
> mean? etypes need not be contiguous themselves. So I guess
> it means "count etypes placed one after another such that the
> displacement between the start of consecutive etypes is equal
> to the extent of the etype in the file." Some clarification
> is needed.
I believe "contiguous" is well-defined in MPI, and needs no
further explanation.
> 244/12-14: Some clarification needed here as well to indicate
> that "datatype" defines a tiling of userbuf. For example,
> something like "The function must copy all \mpiarg{count} data
> items from \mpiarg{filebuf} to \mpiarg{userbuf}, converting each
> data item from file representation to native representation. The
> data layout in \mpiarg{userbuf} is a tiling defined by repeated
> copies of \mpiarg{datatype}."
Is this true? I thought that the datatype covered the whole userbuf.
> 247/25-30: In this case, is seq. consistency guaranteed for
> nonoverlapping accesses? For the case in lines 5-10, it is
> explicitly stated that it is guaranteed.
Yes. It is explicitly stated that it is guaranteed in lines 5-10.
> 247:30-36: I don't understand what this says. Does "precede" on
> line 34 refer to precede in time or precede in the file? Line 27
> says that the default behavior for file handles from different
> opens does not guarantee seq. consistency. I don't understand
> the special case in lines 30-36 for which seq. consistency
> is guaranteed.
Precede is precede in time. There is no special case---the
text defines the conditions under which FILE_SYNC foces consistency.
> 249/3-4: Even explict offsets indivdual file pointers are erroneous.
True, but no exhaustive list is given here---should one be given?
- bill