There is no misunderstanding of the MPI standard or the definition of blocking in the bug3 example. Both bug 3 and the example I provided are valid MPI.
As you say, blocking means the send buffer can be reused when the MPI_Send returns. This is exactly what bug3 is count on.
MPI is a reliable protocol which means that once MPI_Send returns, the application can assume the message will be delivered once a matching recv is posted. There are only two ways I can think of for MPI to keep that guarantee.
1) Before return from MPI_Send, copy the envelop and data to some buffer that will be preserved until the MPI_Recv gets posted
2) delay the return from MPI_Send until the MPI_Recv is posted and then move data from the intact send buffer to the posted receive buffer. Return from MPI_Send
The requirement in the standard is that if libmpi takes option 1, the return from MPI_Send cannot occur unless there is certainty the buffer space exists. Libmpi cannot throw the message over the wall and fail the job if it cannit be buffered.
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
email@example.com wrote on 02/05/2008 02:28:27 AM:
> On Mon, Feb 04, 2008 at 04:23:13PM -0500, Sacerdoti, Federico wrote:
> > Bug3 is a test-case derived from a real, scalable application (desmond
> > for molecular dynamics) that several experienced MPI developers have
> > worked on. Note the MPI_Send calls of processes N>0 are *blocking*; the
> > openmpi silently sends them in the background and overwhelms process 0
> > due to lack of flow control.
> MPI_Send is *blocking* in MPI sense of the word i.e when MPI_Send returns
> send buffer can be reused. MPI spec section 3.4.
> users mailing list