Hi Gleb

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


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


users-bounces@open-mpi.org 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.
>
> --
>          Gleb.
> _______________________________________________
> users mailing list
> users@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users