Hi Adam,
This statement says that an app can't know whether the begin call will synchronize or not, so a portable app must assume that the call does synchronize. However, the earlier statements say that regardless of whether the MPI library implements the begin call as blocking or non-blocking, the app is always guaranteed that the shared file pointer will be updated upon return from the begin call.
Yes but I agree with Dries that there is a contradiction, and it can be interpreted by a developer either way, i.e. the pointer can be either updated in the begin or end call..
With split collectives, the "begin" call that initiates the operation *can* block, but with non-blocking collectives (as currently defined), the "i" call that initiates the operation *never* blocks. It's this difference between split collectives and non-blocking collectives that causes the difficulty here. To efficiently meet the requirements of updating the shared file pointer, we'd really like to update the pointer during the "i" call, but this would require the "i" call to block.
I do not have a strong opinion here, as we don't really use this feature.. But I can see how this could complicate things more to the user and the developer, which makes me more inclined to keep the ordering undefined. That said, we do want to start working on a ticket for new MPI-I/O features that would actually track order inside the implementation for nonblocking file access and manipulation routines (more like queuing).. We discussed that at the last Chicago meeting.. This is not MPI-3.0 bound though :) Thanks, Mohamad