[MPI3-IO] shared file pointer

[Dries Kimpe]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-io/attachments/20120206/356f59cb/attachment-0001.pgp>