[MPI3-IO] shared file pointer

[Adam T. Moody]

Hi Mohamad and Dries,
Yes, I see your point now about "using the corresponding blocking 
collective routines when ... the end call is issued".  I don't think 
that's what the standard intended, but you're very right in that the 
text says two different things.  Some statements say the pointer is 
updated by the call that initiates the operation, i.e., the _begin call, 
but this says the opposite in that an implementation is allowed to do 
all the work (including updating of the pointer) in the _end call.  
Thus, it's not clear whether the pointer will always be updated after 
returning from the _begin call.
-Adam


Mohamad Chaarawi wrote:

>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
>
>
>_______________________________________________
>MPI3-IO mailing list
>MPI3-IO at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io
>  
>