MPI defines only reliable communications -- it's not quite the same thing as UDP.
Hence, if you send something, it is guaranteed to be able to be received. UDP may drop packets whenever it feels like it (e.g., when it is out of resources).
Most MPI implementations will do some form of buffering of unexpected receives. So if process A sends message X to process B, if B hasn't posted a matching receive for message X yet, B will likely silently accept the message under the covers and buffer it (or at least buffer part of it). Hence, when you finally post the matching X receive in B, whatever of X was already received will already be there, but B may need to send a clear-to-send to A to get the rest of the message.
Specifically: if X is "short", A may eagerly send the whole message to B. If X is "long", A may only send the first part of B and wait for a CTS before sending the rest of it.
MPI implementations typically do this in order to conserve buffer space -- i.e., if A sends a 10MB message, there's no point in buffering it at B until the matching receive is made and the message can be received directly into the destination 10MB buffer that B has made available. If B accepted the 10MB X early, it would cost an additional 10MB to buffer it. Ick.
Alternatively, what I think Lukas was trying to suggest was that you can post non-blocking receives and simply test for completion later. This allows MPI to receive straight into the target buffer without intermediate copies or additional buffers. Then you can just check to see when the receive(s) is(are) done.
On Nov 19, 2011, at 10:47 AM, Mudassar Majeed wrote:
> I know about tnÄ±s functÄ±ons, they special requirements like the mpi_irecv call should be made in every process. My processes should not look for messages or implicitly receive them. But messages shuddering go into their msg queues and retrieved when needed. Just like udp communication.
> users mailing list
For corporate legal information go to: