[MPI3-IO] shared file pointer

[Adam T. Moody]

I will say, though, given that we can now have multiple outstanding 
non-blocking collective I/O calls, it would be really nice to be able to 
do the following:

MPI_File_iread_ordered()
MPI_File_iread_ordered()
MPI_File_iread_ordered()
MPI_Waitall()

This provides a natural way for someone to read in three different 
sections from a file -- just issue all the calls and sit back and wait.  
However, this can only be done if the pointer is updated in the 
initiation call.
-Adam


Adam T. Moody wrote:

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