> p4est communication is confined within the major API functions. All > communications initiated in such a function will be terminated before it > returns. Problems with duplicate message IDs can only occur in > multithreaded programs that call such functions concurrently.
I don't think this is enough. Imagine a program that calls the same function twice in a row (e.g. when refining two meshes one after the other). During the first call, the function realizes on processor 0 that it doesn't need to receive any data and just sends what it needs to send, then exits -- in essence it sends two messages on the same communicator with the same tag. On processors 1, there may be more to do; the function needs to receive data from processor 0 but now there are two messages with the same sender and sam tag. I don't think MPI guarantees that they will be delivered in the same order in which they were sent. I admit this is a contrived example. I don't know if something like this ever happens, but I'd hate to have to debug this sort of stuff... W. ------------------------------------------------------------------------- Wolfgang Bangerth email: [email protected] www: http://www.math.tamu.edu/~bangerth/ _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
