<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Pavan,
<div class=""><br class="">
</div>
<div class="">1) The text clearly suffers from ambiguity of interpretation, because there are two different interpretations espoused in this email chain and both have defenders who are not easily swayed to the other position by a re-reading of the text in question.</div>
<div class=""><br class="">
</div>
<div class="">2) Preserving the “physical order” of these operations as presented to the MPI library is a correct implementation choice. I believe there is no argument or ambiguity on that point. However, it is *also* a correct implementation choice to ignore
 that “physical order” even in this case because the MPI library does not know, and cannot determine, *why* that “physical order” happened. From the point-of-view of the MPI library, there is no difference between “A occurred before B because a critical section
 in user-code enforced it” and “A happened before B because of a non-deterministic thread scheduling accident”. Looking at the program as a whole, it is clear that the operations are not "physically concurrent”, e.g. interleaved or happens-before-in-either-order.
 But looking only at the information known to the MPI library (two operations with different thread ids), it is not possible to discriminate between happens-before-in-deterministic-order and happens-before-in-nondeterministic-order. Thus, the operations are
 “logically concurrent even if one physically precedes the other”. The thread id of the calling thread being different gives MPI the permission to ignore physical/chronological ordering, if it chooses to do so - or not, if it decides that is easier/better in
 some way. Only when the thread id is identical for different operations, is the MPI required to preserve physical/chronological ordering.</div>
<div class=""><br class="">
<div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Cheers,</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Dan.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—<br class="">
Dr Daniel Holmes PhD<br class="">
Applications Consultant in HPC Research<br class="">
<a href="mailto:d.holmes@epcc.ed.ac.uk" class="">d.holmes@epcc.ed.ac.uk</a><br class="">
Phone: +44 (0) 131 651 3465<br class="">
Mobile: +44 (0) 7940 524 088<br class="">
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 23 Nov 2018, at 00:32, Balaji, Pavan via mpiwg-p2p <<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" class="">mpiwg-p2p@lists.mpi-forum.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Jeff, all,<br class="">
<br class="">
Sorry, SC took up all of my time so I couldn't respond earlier.<br class="">
<br class="">
I'm not sure what the confusion is.  I don't think the text is ambiguous.  In the user program, the operations are *not* logically concurrent.  They are protected by a critical section.  Thus, I don't think the MPI implementation can ignore their ordering.<br class="">
<br class="">
 -- Pavan<br class="">
<br class="">
<blockquote type="cite" class="">On Nov 15, 2018, at 11:09 AM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com" class="">jeff.science@gmail.com</a>> wrote:<br class="">
<br class="">
Dan has convinced me that the MPI standard is terrible and, while my original interpretation is what we want and which is consistent with the principle of least surprise, it is not guaranteed by the following text.<br class="">
<br class="">
Per our discussion, there are a few options:<br class="">
1) make all MPI_Send logically concurrent, even on a single thread.  this will break stuff and make people sad.<br class="">
2) force MPI to order injection <somehow>, which might for some implementations to add more memory ordering on the send path than they want, particularly if they do not have a TSO memory model.<br class="">
3) add something like MPI_Win_sync that logically orders sends from multiple threads explicitly.<br class="">
4) add MPI_THREAD_SERIALIZED_WITH_EXTRA_SAUCE that does the equivalent of 2 or 3 and thus doesn't cause a performance regression in MPI_THREAD_SERIALIZED.<br class="">
<br class="">
Jeff<br class="">
If a process has a single thread of execution, then any two communications executed by this process are ordered. On the other hand, if the process is multithreaded, then the semantics of thread execution may not define a relative order between two send operations
 executed by two distinct threads. The operations are logically concurrent, even if one physically precedes the other. In such a case, the two messages sent can be received in any order. Similarly, if two receive operations that are logically concurrent receive
 two successively sent messages, then the two messages can match the two receives in either order.
<br class="">
<br class="">
<br class="">
On Thu, Nov 15, 2018 at 10:55 AM Balaji, Pavan via mpiwg-p2p <<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" class="">mpiwg-p2p@lists.mpi-forum.org</a>> wrote:<br class="">
Dan,<br class="">
<br class="">
The matching *is* ordered in this case.  So the program will print 0 followed by 1.<br class="">
<br class="">
MPI does not order delivery of the actual data, but the first message is guaranteed to go into the first buffer.  If the second message ends up going first, the MPI implementation will need to buffer it.<br class="">
<br class="">
 — Pavan<br class="">
<br class="">
Sent from my iPhone<br class="">
<br class="">
On Nov 15, 2018, at 7:56 AM, HOLMES Daniel via mpiwg-p2p <<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" class="">mpiwg-p2p@lists.mpi-forum.org</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Hi Joachim,<br class="">
<br class="">
There is no guarantee of ordering between the two sends because they are logically concurrent. If they were issued on the same thread then MPI guarantees delivery order will be identical to the sequential issuing order.<br class="">
<br class="">
Many MPI libraries are very likely to deliver these messages "in order”, that is, the first one to be called chronologically at the sender process is likely to leave first and therefore likely to arrive first. Interleaving execution of the sending threads may
 change the issuing order on the network and out-of-order networks may change the order of arrival.<br class="">
<br class="">
On the other hand, if an MPI implementation is internally using sequence numbers (or a similar mechanism) to enforce ordering for the same-thread case, then it may also (incidentally) reconstruct the issuing order for this case. However, you cannot rely on
 this behaviour being portable from system to system or from MPI library to MPI library.<br class="">
<br class="">
If you wish to enforce a particular ordering of these messages, then you can use tags to differentiate each from the other. There is an argument for always using tags in this type of situation to increase program readability.<br class="">
<br class="">
Cheers,<br class="">
Dan.<br class="">
—<br class="">
Dr Daniel Holmes PhD<br class="">
Applications Consultant in HPC Research<br class="">
<a href="mailto:d.holmes@epcc.ed.ac.uk" class="">d.holmes@epcc.ed.ac.uk</a><br class="">
Phone: +44 (0) 131 651 3465<br class="">
Mobile: +44 (0) 7940 524 088<br class="">
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT<br class="">
—<br class="">
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.<br class="">
—<br class="">
<br class="">
<blockquote type="cite" class="">On 15 Nov 2018, at 04:16, Joachim Protze via mpiwg-p2p <mpiwg-p2p@lists.mpi-forum.org> wrote:<br class="">
<br class="">
Hi all,<br class="">
<br class="">
I have a question on the "Semantics of Point-to-Point Communication" in a multithreaded context.<br class="">
<br class="">
For me the situation for the code below is not clear, especially with respect to the paragraph in MPI-3.1 p.41, l.10-17 :<br class="">
<br class="">
<br class="">
void test(int rank) {<br class="">
int msg = 0;<br class="">
if (rank == 0) {<br class="">
#pragma omp parallel num_threads(2)<br class="">
#pragma omp critical<br class="">
  {<br class="">
    MPI_Send(&msg, 1, MPI_INT, 1, 42, MPI_COMM_WORLD);<br class="">
    msg++;<br class="">
  }<br class="">
} else if (rank == 1) {<br class="">
  MPI_Recv(&msg, 1, MPI_INT, 0, 42, MPI_COMM_WORLD, MPI_STATUS_IGNORE);<br class="">
  printf("Received %i\n", msg);<br class="">
  MPI_Recv(&msg, 1, MPI_INT, 0, 42, MPI_COMM_WORLD, MPI_STATUS_IGNORE);<br class="">
  printf("Received %i\n", msg);<br class="">
}<br class="">
}<br class="">
<br class="">
Two threads on the first process send a message, the first thread sends 0, the second thread send 1. From OpenMP semantics, the first send happens before the second send.<br class="">
<br class="">
Is there a guarantee, that the other process receives the 0 first?<br class="">
<br class="">
Thanks,<br class="">
Joachim<br class="">
<br class="">
<br class="">
-- <br class="">
Dipl.-Inf. Joachim Protze<br class="">
<br class="">
IT Center<br class="">
Group: High Performance Computing<br class="">
Division: Computational Science and Engineering<br class="">
RWTH Aachen University<br class="">
Seffenter Weg 23<br class="">
D 52074  Aachen (Germany)<br class="">
Tel: +49 241 80- 24765<br class="">
Fax: +49 241 80-624765<br class="">
protze@itc.rwth-aachen.de<br class="">
www.itc.rwth-aachen.de<br class="">
<br class="">
_______________________________________________<br class="">
mpiwg-p2p mailing list<br class="">
mpiwg-p2p@lists.mpi-forum.org<br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p<br class="">
</blockquote>
<br class="">
The University of Edinburgh is a charitable body, registered in<br class="">
Scotland, with registration number SC005336.<br class="">
_______________________________________________<br class="">
mpiwg-p2p mailing list<br class="">
mpiwg-p2p@lists.mpi-forum.org<br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p<br class="">
</blockquote>
_______________________________________________<br class="">
mpiwg-p2p mailing list<br class="">
<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" class="">mpiwg-p2p@lists.mpi-forum.org</a><br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p<br class="">
<br class="">
<br class="">
-- <br class="">
Jeff Hammond<br class="">
jeff.science@gmail.com<br class="">
http://jeffhammond.github.io/<br class="">
</blockquote>
<br class="">
_______________________________________________<br class="">
mpiwg-p2p mailing list<br class="">
<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" class="">mpiwg-p2p@lists.mpi-forum.org</a><br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>