<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="">
<div class="">
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
</div>
Hi Alain,</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I could not find anything explicitly stating that MPI_Iprobe would <br class="">
initiate a receive the way MPI_Irecv does.</div>
</blockquote>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
This is because the probe functions do not initiate a receive the way a receive does; they only probe the matching list and report back to the user but do not change what they find there.</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Your modified example is guaranteed to deadlock using any standard-conforming MPI library. The MPI_SSEND must not complete before a matching receive operation has been started and has matched. The matching receive operation (the MPI_IRECV in rank 1) cannot
 be reached because the MPI_RECV must not complete before a matching send operation has been started. The matching send operation (the MPI_SEND in rank 0) cannot be reached because the MPI_SSEND is blocked. The MPI_IPROBE is not a receive operation and does
 not cause a match to happen - it is therefore not relevant to the deadlock situation described above.</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Your modified example can be fixed by replacing MPI_IPROBE with MPI_MPROBE (note this a blocking function) and replacing MPI_IRECV with MPI_IMRECV, although a nonblocking function immediately followed by a call to MPI_WAIT is better expressed by a blocking
 function, i.e. MPI_MRECV in this case.</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
The example must use the blocking MPI_MPROBE rather than the nonblocking MPI_IMPROBE because the match for the MPI_SSEND must occur before the MPI_RECV can complete (because that requires the MPI_SEND to be reached in rank 0, which requires that the MPI_SSEND
 completes, which requires that it must have been matched in rank 1, which requires that the mprobe must be complete not just started).</div>
<div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br 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="">
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 13 Sep 2018, at 15:08, <a href="mailto:mpi-comments-request@lists.mpi-forum.org" class="">
mpi-comments-request@lists.mpi-forum.org</a> wrote:</div>
<div class="">
<div class=""><br class="">
----- Original Message -----<br class="">
<br class="">
Hi, <br class="">
(text location provided w.r.t MPI 3.1 <a href="https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf" class="">
https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf</a>)<br class="">
<br class="">
a) In 3.2.4, page 29, there is a discussion regarding the size of the <br class="">
buffer and size of the actual message with an "advice to users" section <br class="">
stating that : <br class="">
"The MPI_PROBE function described in Section 3.8 can be used to receive <br class="">
messages of unknown length."<br class="">
<br class="">
b) There is no such discussion in 3.7.2 so one could assume (maybe too <br class="">
optimistically) that the same advice applies w.r.t. MPI_Iprobe.<br class="">
<br class="">
c) In 3.8.1. page 66 line 9 "The MPI implementation of MPI_PROBE and <br class="">
MPI_IPROBE needs to guarantee progress: [calling those functions, msg <br class="">
should arrive eventually if send and not intercepted].<br class="">
<br class="">
d) The "Progress" note in 3.7.4, illustrated by example 3.14, seems to <br class="">
indicate that a synchronous send can not be blocked if a recv has been <br class="">
posted regardless of the completion of that receive.<br class="">
<br class="">
But I could not find anything explicitly stating that MPI_Iprobe would <br class="">
initiate a receive the way MPI_Irecv does. <br class="">
That is, a slightly modified 3.14 example:<br class="">
CALL MPI_COMM_RANK(comm, rank, ierr)<br class="">
IF (RANK.EQ.0) THEN<br class="">
   CALL MPI_SSEND(a, n, MPI_REAL, 1, 0, comm, ierr)<br class="">
   CALL MPI_SEND(b, 1, MPI_REAL, 1, 1, comm, ierr)<br class="">
ELSE IF (rank.EQ.1) THEN<br class="">
   CALL MPI_IPROBE(0, 0, comm, flag, status1, ierr)<br class="">
   CALL MPI_RECV(b, 1, MPI_REAL, 0, 1, comm, status2, ierr)<br class="">
   ... extract size info from status1  once available ....<br class="">
   CALL MPI_IRECV(a, n, MPI_REAL, 0, 0, comm, r, ierr)<br class="">
   CALL MPI_WAIT(r, status, ierr)<br class="">
END IF<br class="">
<br class="">
could deadlock in a correct MPI implementation.<br class="">
<br class="">
If I am correct in assuming that the MPI standard ask for the MPI_Iprobe <br class="">
to progress, it is not required to initiate. If true, it means the the <br class="">
point a) above does not extend to the non blocking communications and <br class="">
that the MPI does not provide a way to receive messages of unknown size <br class="">
whithout adding more opportunities for deadlocks. <br class="">
Am I correct ? and if yes, does that indicate that the discussion and <br class="">
advice of point a could be adapted and explicitly added for the non <br class="">
blocking case (point b).<br class="">
Thanks<br class="">
<br class="">
Alain<br class="">
<br class="">
End of mpi-comments Digest, Vol 8, Issue 1<br class="">
******************************************<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>