<html><body>
<p>The standard already says:<br>
<font face="CMR10">If a sender sends two messages in succession to the</font><br>
<font face="CMR10">same destination, and both match the same receive, then this operation cannot receive the</font><br>
<font face="CMR10">second message if the first one is still pending. If a receiver posts two receives in succession,</font><br>
<font face="CMR10">and both match the same message, then the second receive operation cannot be satisfied</font><br>
<font face="CMR10">by this message, if the first one is still pending. This requirement facilitates matching of</font><br>
<font face="CMR10">sends to receives. It guarantees that message-passing code is deterministic,</font><br>
<br>
I think that already provides the appropriate guarantee.   Two concurrent threads making MPI calls do not provide any enforcement of "<font face="CMR10">succession</font>" and the standard points this out to be helpful.  It should not really have been necessary to say this.  <br>
<br>
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 "<font face="CMR10">succession</font>" is ambiguous, MPI makes no guarantee of disambiguation.  Where "<font face="CMR10">succession</font>" is clear cut, MPI will reflect the succession order.<br>
<br>
<br>
Dick Treumann  -  MPI Team           <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-22-bounces@lists.mpi-forum.org wrote on 03/27/2009 01:25:29 PM:<br>
<br>
> [image removed] </tt><br>
<tt>> <br>
> Re: [Mpi-22] Ordering guarantees and multiple threads</tt><br>
<tt>> <br>
> Greg Bronevetsky </tt><br>
<tt>> <br>
> to:</tt><br>
<tt>> <br>
> MPI 2.2, MPI 2.2</tt><br>
<tt>> <br>
> 03/27/2009 01:27 PM</tt><br>
<tt>> <br>
> Sent by:</tt><br>
<tt>> <br>
> mpi-22-bounces@lists.mpi-forum.org</tt><br>
<tt>> <br>
> Please respond to "MPI 2.2"</tt><br>
<tt>> <br>
> At 09:35 AM 3/27/2009, Darius Buntinas wrote:<br>
> <br>
> >I've just created a ticket:<br>
> >   https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144<br>
> >to suggest that we strengthen the ordering guarantees between sends (and<br>
> >receives) from different threads.<br>
> ><br>
> >I think that the real question here is whether the potential benefit to<br>
> >the user outweighs the potential for optimization in a multithreaded<br>
> >implementation.<br>
> ><br>
> >Please have a look at it and feel free to comment.<br>
> <br>
> I like the spirit of this proposal but in practice it will be hard to <br>
> specify. In particular, consider the sentence "two sends do not <br>
> overlap if the first MPI_Send() returns before the second MPI_Send() <br>
> is called". The word "before" here is only properly defined on a <br>
> sequentially consistent memory. On any other memory model "before" is <br>
> only defined by synchronization primitives supplied by the shared <br>
> memory system. As such, I don't know how to be precise about <br>
> something like "before" without talking about the shared memory <br>
> system. This will be hard because we'll need to talk about concepts <br>
> that all these systems share but for which they all provide different <br>
> primitives and semantics. I don't know how the wider forum will react <br>
> to such a specification. However, I agree that something like this is <br>
> necessary.<br>
> <br>
> Greg Bronevetsky<br>
> Post-Doctoral Researcher<br>
> 1028 Building 451<br>
> Lawrence Livermore National Lab<br>
> (925) 424-5756<br>
> bronevetsky1@llnl.gov<br>
> <a href="http://greg.bronevetsky.com">http://greg.bronevetsky.com</a> <br>
> <br>
> _______________________________________________<br>
> mpi-22 mailing list<br>
> mpi-22@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><br>
</tt></body></html>