[MPI3-IO] shared file pointer

[Mohamad Chaarawi]

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