* Quincey Koziol <[email protected]> [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