[MPI3-IO] [EXTERNAL] New MPI-IO routines

[Rob Ross]

Hi,

In terms of the broader context, I believe that messages to the same destination with matching tags are already ordered:

---
Messages are non-overtaking: If a sender sends two messages in succession to the same destination, and both match the same receive, then this operation cannot receive the second message if the first one is still pending. If a receiver posts two receives in succession, and both match the same message, then the second receive operation cannot be satisfied by this message, if the first one is still pending. This requirement facilitates matching of sends to receives. It guarantees that message-passing code is deterministic, if processes are single-threaded and the wildcard MPI_ANY_SOURCE is not used in receives. (Some of the calls described later, such as MPI_CANCEL or MPI_WAITANY, are additional sources of nondeterminism.)
---

So in the point-to-point context, I think this concept is already there. The I/O routines just happen to be weaker? Been a while since I last looked at this stuff though, so I may be misremembering.

Rob

On May 24, 2012, at 3:46 PM, Mohamad Chaarawi wrote:

> Hi Jay,
> 
> On 5/24/2012 3:08 PM, Lofstead, Gerald F II wrote:
>> I can see the usefulness of this beyond the SWMR case (essentially queue a
>> bunch of IO ops in the background and come back when they are all done)
> 
> yes that is definitely useful in many cases, especially if the file manipulation routines are nonblocking too..
> 
>> and wonder is there a broader agenda that should be looked at for this?
>> For example, is the non-blocking, but ordered idea something useful for
>> messaging as well? Personally, I think so. Given that, is it worth
>> exploring this in a broader context to add the non-blocking, ordered style
>> to MPI as a whole?
> 
> I am not aware of anyone exploring this beyond I/O. I can't answer the question if it's worthwhile to do this for ALL MPI, but I don't see why it would not be possible.. Datatype creation is something that I could think of, which would benefit well from this and would go nice with the I/O version of such routines.
> 
>> 
>> Other than an explicit queue mechanism to execute these in series, what
>> are the complexity problems you envision? It seems really straightforward.
> 
> There's that, and there is the consistency semantics issue, where the library needs to make sure that the operations are atomic.
> 
> Thanks,
> Mohamad
> 
>> 
>> Jay Lofstead
>> 
>> On 5/24/12 12:39 PM, "Mohamad Chaarawi"<chaarawi at hdfgroup.org>  wrote:
>> 
>>> Hi all,
>>> 
>>> We would like to get a discussion going on adding new routines to the
>>> standard that would support non-blocking but ordered access routines,
>>> and non-blocking ordered file manipulation routines. They would be two
>>> separate tickets but they share similar semantics.
>>> 
>>> So basically what we would like is that when we call:
>>> 1) iwrite_at()
>>> 2) iread_at()
>>> 3) iwrite_at()
>>> ...
>>> 4) waitall()
>>> 
>>> We would like to see the data accessed as if the calls were blocking.
>>> This could translate to something like:
>>> iwrite_at()
>>> iwait()
>>> iread_at()
>>> iwait()
>>> iwrite_at()
>>> iwait()
>>> 
>>> There is ofcourse no such thing as iwait, but you get the idea :-)
>>> 
>>> Our use case for this is the SWMR functionality that is being worked on,
>>> where the non-blocking version would require the MPI library to remember
>>> the order in which the operations were called; otherwise I don't see how
>>> we can enforce this ordering and at the same time keep the entire I/O
>>> access nonblocking.
>>> We probably need to rename the routines (something other than the i
>>> prefix) because the semantics are different from the current
>>> non-blocking routines. Maybe aread/awrite (a for asynchronous).
>>> 
>>> Another feature we are considering is the non-blocking file manipulation
>>> routines. Similarly to the semantics described above, the library needs
>>> to remember the order they are called.
>>> iopen
>>> iset_view
>>> iwrite
>>> iclose
>>> ...
>>> waitall()
>>> 
>>> Again since the semantics are different in the way other immediate
>>> routines are defined, we need to reconsider the naming.
>>> 
>>> Any thoughts?
>>> 
>>> 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
> 
> _______________________________________________
> MPI3-IO mailing list
> MPI3-IO at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io