[MPI3-IO] shared file pointer

[Dries Kimpe]

* Quincey Koziol <koziol at hdfgroup.org> [2012-02-01 13:38:32]:

[...]

> > In other words, the example above has -- according to the standard -- two
> > outcomes: either the collective call logically executes before the
> > independent, or the independent logically executes before the collective.

> 	Is there a well-defined behavior in the standard for this?

I'm not exactly sure what you're asking for, but at least for the split
collectives, the standard literally leaves the implementor the choice of
calling the blocking call in either the split collective start or end.

Hence the two possible outcomes.

Now, the fact that his is the case for the split collectives doesn't mean
that this has to be the case for the non-blocking versions.
It could also just be an oversight in the standard.

> > I'm not sure that doing 2 iread_ordered calls would be legal or -- if
> > legal -- forced to act as if the shared file pointer was updated before
> > the read_shared() call (or the 2nd iread_ordered for that matter).

> 	Hmm, maybe nonblocking (both independent & collective) I/O on a shared file pointer doesn't make sense at all then?

I would not go that far. It might not make sense to have _multiple_
outstanding non-blocking shared file pointer calls on a single MPI File
handle, at least not if one wants to rely on a specific ordering.

For example, it could be perfectly legal to have two outstanding
non-blocking shared file pointer routines, while at the same time
guaranteeing atomic shared file pointer updates but /not/ guaranteeing the
ordering between the two.

I can definitely think of an application scenario where this would make
sense.

I would have to look up if this is the way the standard looks at it, but
one possible way of reasoning about the non-blocking collectives is to
consider them to be blocking from the time they are started up to the time
they are completed by wait/test/...

In this case, the example reduces to having two threads doing a
MPI_File_read_ordered on the same file handle.

It is perfectly valid to ask what happens in MPI 2.2 in this case.

Clearly, for the split collectives, doing this is /not/ legal as the
standard explicitly prohibits having more than one split collective on the
same file handle at the same time.

But really, somebody with better knowledge of the non-blocking collectives
should answer what happens if two MPI_Iscan operations are executed on the
same communicator.

If in this case, the standard can guarantee ordering, than it is trivial
to do the same for MPI_File_iread_ordered.

Unfortunately, that still leaves the problematic case of mixing
independent shared file pointer calls with non-blocking shared fp
collectives.  As I pointed out before, for split collectives, in MPI-2.2,
the standard leaves what happens up to the implementation as the
implementation is free to call the blocking call in the _begin or _end
routine of the split collective.

However, the behaviour is not undefined as in any case, there will be a
logical ordering and the independent and split collective will not return
the same data.


  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/5cbbc954/attachment-0001.pgp>