[MPI3-IO] shared file pointer

[Dries Kimpe]

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

> > 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.
> Well, they *can* complete out of order (not match though!) you need to
> make sure the order it preserved.

Good point.

For this to work, we need an atomic Iscan + update fp.
In other words, we also have to order FP update operations.
But that is pretty easy to do, by using an attribute on the file handle.

MPI_File_iread_ordered:
 lock
  -> get sequence number from file handle attribute, store number
     with operation
  -> add our number at the end of a list in attribute on file handle
 unlock

 start and wait (non-blocking) for iscan

 if iscan completes: wait until the number at the front of the list
  (in attribute is ours).
 if it is:
   update shared fp and remove from list
 else
   wait.

 do ifile_read_at.


Obviously, there are better ways of doing this. The main point is that we
need to introduce an extra dependency on the update for the shared fp so
that we wait until any earlier operation already updated the shared fp.

I guess the same technique (and attribute) could be used for the
independent shared fp operations, but I'm really no fan of that. 

If only because when we do that, the independent shared fp update really
becomes collective, as it will block until some other MPI rank completes
the collective shared fp update.

I would prefer to leave that as undefined ordering, because to me it
really feels like doing two non-blocking receives using the same target
buffer.

  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/6b953d73/attachment-0001.pgp>