[MPI3-IO] shared file pointer

[Mohamad Chaarawi]

Hi Adam,

On 2/22/2012 7:25 PM, Adam T. Moody wrote:
> 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.

I don't see how the current proposal would prevent you from doing this..
The only ordering that we say is undefined is when you mix collective 
and independent operations..

Thanks,
Mohamad

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