[MPI3-IO] shared file pointer

[Mohamad Chaarawi]

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.

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

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