[MPI3-IO] shared file pointer

[Adam T. Moody]

Hi guys,
My interpretation of the standard is that the following use of split 
collectives is ok:

MPI_File_read_ordered_begin()
MPI_File_read_shared()
MPI_File_read_ordered_end()

This understanding comes from the following:

p405, 17-9
"In general, each I/O operation leaves the file pointer pointing to the 
next data itme after the last one that is accessed by the operation.  In 
a nonblocking or split collective operation, the pointer is updated by 
the call that initiates the I/O, possibly before the access completes."

and:

p417, 1-2
"After a shared file pointer operation is initiated, the shared file 
pointer is updated to point to the next etype after the last one that 
will be accessed."

Assuming this interpretation is correct, when removing split collectives 
from an existing app, then it's natural for the user to want to replace 
the above with:

MPI_File_iread_ordered()
MPI_File_read_shared()
MPI_Wait()

If possible, we should strive to allow this.  I can see cases where it 
would be useful, e.g., rank 0 always reads some special fields, perhaps 
the header of the next shared array.  And it's consistent with current 
behavior of the split collectives.

However, to do this, the read_shared() call would need to block until 
all procs have called iread_ordered().  This does pose two difficulties:
    1) It requires MPI to track any outstanding non-blocking collective 
calls so that it knows to wait on them.
    2) It forces read_shared() into this limbo between being local / not 
local.  It's supposed to be a local call, but in this context, it can't 
return until all other procs have called the collectives that come 
before it.  So is it still "local"?

Assuming #1 doesn't impose too big a burden on MPI implementations, then 
we need to decide whether the problem in #2 is a show stopper or not.
-Adam



Finally, there is

Quincey Koziol wrote:

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