[MPI3-IO] shared file pointer

[Dries Kimpe]

* Torsten Hoefler <htor at illinois.edu> [2012-02-01 15:04:41]:

> > 	Torsten?  (CC'd)
> There are obviously no filehandles in NBC. The scan operations match in
> issue-order and the buffers specified have to be disjunct (as for any
> nonblocking communication in MPI). I.e., the two NBCs do not influence
> each other from a correctness perspective.

Meaning that the ordering issue for non-blocking collectives (but not
mixed case) is straigtforward, right?

Implementation of MPI_File_Iread_ordered:
   MPI_Iscan (amount of local data)
   <make progress>
   When MPI_Iscan completes:
   update shared file pointer <atomic: one rank can do this>
   MPI_File_iread_at 


As long as it is possible to adjust and get the shared file pointer
(which is what I'll be proposing in the ticket I've talked about to you
guys) it is possible to do this and not have 'undefined' behaviour.

Also note that currently, ROMIO already has this functionality.
(As this is how MPI_File_read_shared is implemented).

Because of the MPI_Iscan properties, a second MPI_File_iread_ordered could
not proceed before the first one finished the scan phase, hence they would
be properly ordered.

Now, for mixing in indepentent shared FP operations, while not undefined,
the ordering would not be determined and will depend on what happens on
other nodes and other things.

As in:

(1) MPI_File_iread_ordered
...
(2) MPI_File_read_shared

(3) MPI_Wait ()

If (1) can complete the scan before the call to (2), (1) will appear to
logically execute before (2). In all other cases, (1) will logically
execute before (2).

   Dries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-io/attachments/20120201/5d7633a4/attachment-0001.pgp>