[MPI3-IO] shared file pointer

[Dries Kimpe]

* Quincey Koziol <koziol at hdfgroup.org> [2012-02-01 17:31:39]:

[...]

> > 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.

> 	I'm neutral on it from a user (i.e. HDF5) perspective, since I
> 	don't think anyone will actually use the feature.  But, if someone
> 	did, would an undefined ordering be an OK thing for them too?  If
> 	so, we can say that the order is undefined in the standard and
> 	leave it at that...

There might be some use in 'undefined ordering' as opposed to 'illegal'
for those application that don't care about the ordering.

Applications that do rely on the ordering can easily use the existing MPI
functions to enforce ordering.

So, the way I see it: 2 choices:
1) Say order is undefined in the standard (basically there's a precedent
with the split collective versions).
2) Say it is illegal. The user can duplicate the file handle and easily
implement their own version of what they need.

(2) is easier for the implementor.

  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/20120202/f65c5755/attachment-0001.pgp>