[MPI3-IO] shared file pointer

[Quincey Koziol]

Hi Dries,

On Feb 1, 2012, at 2:39 PM, Dries Kimpe wrote:

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

	*bleh*

> Now, the fact that this 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 leaning that way right now... :-)

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

	But if they weren't ordered, the second operation could have undefined behavior, depending on when the file offset was changed.  (Since it will depend on the current offset, for where it's operation gets performed)

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

	Torsten?  (CC'd)

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

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

	The behavior is definitely undefined from the application's perspective... :-/

	Quincey