[Mpi-comments] Non blocking receive of unknown size

[Alain Miniussi]

Hi,

(text location provided w.r.t MPI 3.1 
https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf)

  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 :
"The MPI_PROBE function described in Section 3.8 can be used to receive 
messages of unknown length."

  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.

  c) In 3.8.1. page 66 line 9 "The MPI implementation of MPI_PROBE and 
MPI_IPROBE needs to guarantee progress: [calling those functions, msg 
should arrive eventually if send and not intercepted].

  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.

But I could not find anything explicitly stating that MPI_Iprobe would 
initiate a receive the way MPI_Irecv does.

That is, a slightly modified 3.14 example:

CALL MPI_COMM_RANK(comm, rank, ierr)
IF (RANK.EQ.0) THEN
     CALL MPI_SSEND(a, n, MPI_REAL, 1, 0, comm, ierr)
     CALL MPI_SEND(b, 1, MPI_REAL, 1, 1, comm, ierr)
ELSE IF (rank.EQ.1) THEN
     CALL MPI_IPROBE(0, 0, comm, flag, status1, ierr)
     CALL MPI_RECV(b, 1, MPI_REAL, 0, 1, comm, status2, ierr)
     ... extract size info from status1  once available ....
     CALL MPI_IRECV(a, n, MPI_REAL, 0, 0, comm, r, ierr)
     CALL MPI_WAIT(r, status, ierr)
END IF

could deadlock in a correct MPI implementation.

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.

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).

Thanks

Alain


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-comments/attachments/20180913/19ca0060/attachment.html>