[Mpi-22] Ordering guarantees and multiple threads

[Richard Treumann]

The standard already says:
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,

I think that already provides the appropriate guarantee.   Two concurrent
threads making MPI calls do not provide any enforcement of "?succession"
and the standard points this out to be helpful.  It should not really have
been necessary to say this.

Explicit temporal ordering of actions on otherwise concurrent threads by an
application is common and it is not the job of the MPI standard to say how
this is to be done.  MPI should probably only say in any situation where
"?succession" is ambiguous, MPI makes no guarantee of disambiguation.
Where "succession" is clear cut, MPI will reflect the succession order.

Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

mpi-22-bounces_at_[hidden] wrote on 03/27/2009 01:25:29 PM:

> [image removed]
>
> Re: [Mpi-22] Ordering guarantees and multiple threads
>
> Greg Bronevetsky
>
> to:
>
> MPI 2.2, MPI 2.2
>
> 03/27/2009 01:27 PM
>
> Sent by:
>
> mpi-22-bounces_at_[hidden]
>
> Please respond to "MPI 2.2"
>
> At 09:35 AM 3/27/2009, Darius Buntinas wrote:
>
> >I've just created a ticket:
> >   https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144
> >to suggest that we strengthen the ordering guarantees between sends (and
> >receives) from different threads.
> >
> >I think that the real question here is whether the potential benefit to
> >the user outweighs the potential for optimization in a multithreaded
> >implementation.
> >
> >Please have a look at it and feel free to comment.
>
> I like the spirit of this proposal but in practice it will be hard to
> specify. In particular, consider the sentence "two sends do not
> overlap if the first MPI_Send() returns before the second MPI_Send()
> is called". The word "before" here is only properly defined on a
> sequentially consistent memory. On any other memory model "before" is
> only defined by synchronization primitives supplied by the shared
> memory system. As such, I don't know how to be precise about
> something like "before" without talking about the shared memory
> system. This will be hard because we'll need to talk about concepts
> that all these systems share but for which they all provide different
> primitives and semantics. I don't know how the wider forum will react
> to such a specification. However, I agree that something like this is
> necessary.
>
> Greg Bronevetsky
> Post-Doctoral Researcher
> 1028 Building 451
> Lawrence Livermore National Lab
> (925) 424-5756
> bronevetsky1_at_[hidden]
> http://greg.bronevetsky.com
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20090327/4ee5cbfc/attachment.html>