The MPI standard allows an implementation to run out of resources, so MPICH is compliant here :-). As Jeff mentioned it is a "quality of implementation" issue and some implementations might be able to handle it better than others. Simply queuing the sends on the sender side can lead to deadlocks, so something trickier is needed (imagine that the receiver posts a blocking receive with tag A followed by a million receives with tag B, and the sender sends a million messages with tag B then one message with tag A. If we queue the messages at the sender, the receiver will never receive the message with tag A and the program deadlocks). We've seen such "flow-control" problems before (some in out test suite), and generally the solution is to add some sort of synchronization in the application, e.g., to an Ssend (or Issend so long as you wait on the requests often enough) once in a while to let the receiver catch up. -d On Nov 27, 2012, at 2:50 AM, Matthieu Dorier wrote:

Hello,

I have a program that include two processes, one is doing a lot of MPI_Isend, the other one loops, receives the messages using MPI_Irecv and treats them. I'd like to know what the MPI-2 standard says, and what Mpich2 does, if the first process is too fast and the second process cannot keep up with the number of messages sent. Is the first process supposed to eventually block, waiting for the messages to be received, or will the application crashes?

Thanks

Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss