> > I am well aware of the scaling problems related to the standard > send requirements in MPI. I t is a very difficult issue. > > However, here is what the standard says: MPI 1.2, page 32 lines 29-37 > > [...]
I'm well aware of those words. They are highlighted (in pink no less) in on page 50 of my copy of "MPI: The complete reference, Volume 1, The MPI Core" :) > > If there are people who want to argue that this is unclear or that > it should be changed, the MPI Forum can and should take up the > discussion. I think this particular wording is pretty clear. I don't dispute that they are clear, but I think they should be changed :) > > The piece of MPI standard wording you quote is somewhat ambiguous: > ============ > The amount > of space available for buffering will be much smaller than program data > memory on many systems. Then, it will be easy to write programs that > overrun available buffer space. > ============ > But note that this wording mentions a problem that an application > can create but does not say the MPI implementation can fail the > job. What kind of errors are meant by "Errors may occur when lack of resources prevent the execution of an MPI call."? > The language I have pointed to is where the standard says what > the MPI implementation must do. Understood. There's also this advice to users in the Standard: A program is ``safe'' if no message buffering is required for the program to complete. One can replace all sends in such program with synchronous sends, and the program will still run correctly. This conservative programming style provides the best portability, since program completion does not depend on the amount of buffer space available or in the communication protocol used. > > The "lack of resource" statement is more about send and receive > descriptors than buffer space. If I write a program with an infinite > loop of MPI_IRECV postings the standard allows that to fail. > Agreed. And it doesn't need to be infinite. We've had to explain to our users that they can't have a loop that posts a receive for every other process in the job.... Not to muddy the point, but if there's enough ambiguity in the Standard for people to ignore the progress rule, then I think (hope) there's enough ambiguity for people to ignore the sender throttling issue too ;) -Ron
