<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Gilles,</p>
<p>Not so sure, that argument could be made for MPI_Irecv (used in
the original code), which is not allowed to deadlook. There is a
special send mode called "ready" that explicitly assume that the
recv call has been made, but that's just an optimization.<br>
From 3.4: "Thus, a send in standard mode can be started whether or
not a matching receive has been posted."</p>
<p>I kept the MPI_Ssend because it was in the original example, but
the question still hold if replaced with MPI_Send which leaves
more choice to the implementation.</p>
<p>If MPI_Iprobe initiate a reception (which is not explicitly
stated, and which is basically my question) the first MPI_Send
could just wait for that event and send the data (maybe using the
buffered mode).</p>
<p> An argument could be made that since the receiver buffer is not
provided, and the implementation could choose a communication mode
requiring that a user provided buffer to be ready ready. But then
the same argument could be made for MPI_PROBE, and state 3.8 that:
<br>
"The MPI_PROBE, MPI_IPROBE, MPI_MPROBE, and MPI_IMPROBE operations
allow incoming messages to be checked for, without actually
receiving them."<br>
and later on (p 65):<br>
"it is not necessary to receive a message immediately after it has
been probed for, and the same message may be probed for several
times before it is received."<br>
</p>
<p>So it seems that the implementation is expected to send the size
first, for MPI_[IM]probe to look it up, but that the message
itself can be kept pending and that the matching send can be kept
blocked until the message is actually copied. Put another way, the
message size must be made available to the receiver no matter what
communication protocol is chosen.</p>
<p>Cheers</p>
<p>Alain<br>
</p>
<div class="moz-cite-prefix">On 13/09/2018 15:24, gilles--- via
mpi-comments wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20180913132427.00003F02.0180@rist.or.jp">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<p> Alain,</p>
<p> </p>
<p>Regardless of what the standard says or how it is interpreted,
your example can simply deadlock if rank 1 returns from
MPI_Iprobe()</p>
<p>before rank 0 calls MPI_Ssend().</p>
<p> </p>
<p>Cheers,</p>
<p> </p>
<p>Gilles</p>
<p>----- Original Message -----</p>
<blockquote style="margin:1em 0;padding-left:1em;border-left:2px
solid blue;">
<p>Hi, </p>
<p>(text location provided w.r.t MPI 3.1 <a
class="moz-txt-link-freetext"
href="https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf"
moz-do-not-send="true">https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf</a>)</p>
<p> a) In 3.2.4, page 29, there is a discussion regarding the
size of the buffer and size of the actual message with an
"advice to users" section stating that : <br>
"The MPI_<span class="highlight">PROBE</span> function
described in Section 3.8 can be used to receive messages of
unknown length."</p>
<p> b) There is no such discussion in 3.7.2 so one could assume
(maybe too optimistically) that the same advice applies w.r.t.
MPI_Iprobe.</p>
<p> c) In 3.8.1. page 66 line 9 "The MPI implementation of
MPI_PROBE and MPI_IPROBE needs to guarantee <span
class="highlight selected">progre</span>ss: [calling those
functions, msg should arrive eventually if send and not
intercepted].</p>
<p> d) The "Progress" note in 3.7.4, illustrated by example
3.14, seems to indicate that a synchronous send can not be
blocked if a recv has been posted regardless of the completion
of that receive.</p>
<p>But I could not find anything explicitly stating that
MPI_Iprobe would initiate a receive the way MPI_Irecv does. </p>
<p>That is, a slightly modified 3.14 example:</p>
<p>CALL MPI_COMM_RANK(comm, rank, ierr)<br>
IF (RANK.EQ.0) THEN<br>
CALL MPI_SSEND(a, n, MPI_REAL, 1, 0, comm, ierr)<br>
CALL MPI_SEND(b, 1, MPI_REAL, 1, 1, comm, ierr)<br>
ELSE IF (rank.EQ.1) THEN<br>
CALL MPI_IPROBE(0, 0, comm, flag, status1, ierr)<br>
CALL MPI_RECV(b, 1, MPI_REAL, 0, 1, comm, status2, ierr)<br>
... extract size info from status1 once available ....<br>
CALL MPI_IRECV(a, n, MPI_REAL, 0, 0, comm, r, ierr)<br>
CALL MPI_WAIT(r, status, ierr)<br>
END IF</p>
<p>could deadlock in a correct MPI implementation.<br>
<br>
If I am correct in assuming that the MPI standard ask for the
MPI_Iprobe to progress, it is not required to initiate. If
true, it means the the point a) above does not extend to the
non blocking communications and that the MPI does not provide
a way to receive messages of unknown size whithout adding more
opportunities for deadlocks. </p>
<p>Am I correct ? and if yes, does that indicate that the
discussion and advice of point a could be adapted and
explicitly added for the non blocking case (point b).</p>
<p>Thanks</p>
<p>Alain</p>
<p> </p>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mpi-comments mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpi-comments@lists.mpi-forum.org">mpi-comments@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.mpi-forum.org/mailman/listinfo/mpi-comments">https://lists.mpi-forum.org/mailman/listinfo/mpi-comments</a>
</pre>
</blockquote>
<br>
</body>
</html>