[MPI3-IO] shared file pointer

[Quincey Koziol]

Hi Mohamad,

On Feb 12, 2012, at 11:52 AM, Mohamad Chaarawi wrote:

> Hi All,
> 
> So after laying out these choices, I see 3 options for the nbcio ticket:
> 
> 1) Keep it the way it is, and adding an advise to users saying that intermixing nonblocking collective shared fp operation and independent shared fp operations is undefined.
> 
> 2) Make the previous case illegal.
> 
> 3) remove the nonblocking ordered operations from this ticket (to be handled in a separate ticket)
> 
> keep in mind, as mentioned previously, we can't provide a prototype implementation for those routines. From our side, if the forum accepts only a pseudo code implementation for those routines, we  would like to proceed with option 1, otherwise we would go with option 3.

	Sounds good to me.

	Quincey

> 
> Any other opinions?
> 
> Thanks,
> Mohamad
> 
> On 2/6/2012 1:19 PM, Dries Kimpe wrote:
>> 
>> Yes, that's an accurate summary.
>> 
>>   Dries
>> 
>> * Mohamad Chaarawi <chaarawi at hdfgroup.org> [2012-02-06 10:48:50]:
>> 
>>> Hi Dries,
>>> I'm jumping late on this thread, but to summarize so far (and correct me 
>>> if I made a mistake understanding), we have two cases:
>>> 1) two non-blocking collective shared FP operations:
>>> 	MPI_File_iread_ordered
>>> 	MPI_File_iread_ordered
>>> This will be ordered in the sense that the user will see that the first 
>>> operations will occur before the second one.
>>> 2) mixed collective and independent
>>>          MPI_File_iread_ordered
>>> 	MPI_File_read_shared
>>> Where the choices that you mentioned apply, right?
>>>   * make that case illegal
>>>   * make it undefined
>>> As you mentioned that since the split collectives leave it as undefined, 
>>> makes me lean more towards keeping it that way.
>>> Thanks,
>>> Mohamad
>> 
>> 
>>> On 02/02/2012 04:22 PM, Dries Kimpe wrote:
>>>> There might be some use in 'undefined ordering' as opposed to 'illegal'
>>>> for those application that don't care about the ordering.
>>>> Applications that do rely on the ordering can easily use the existing MPI
>>>> functions to enforce ordering.
>>>> So, the way I see it: 2 choices:
>>>> 1) Say order is undefined in the standard (basically there's a precedent
>>>> with the split collective versions).
>>>> 2) Say it is illegal. The user can duplicate the file handle and easily
>>>> implement their own version of what they need.
>>>> (2) is easier for the implementor.
>> 
>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> MPI3-IO mailing list
> MPI3-IO at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-io/attachments/20120213/5af98f41/attachment-0001.html>