-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> 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.
- From http://www.mpi-forum.org/docs/mpi-11-html/node41.html#Node41 Order Messages are non-overtaking: If a sender sends two messages in succession to the same destination, and both match the same receive, then this operation cannot receive the second message if the first one is still pending. If a receiver posts two receives in succession, and both match the same message, then the second receive operation cannot be satisfied by this message, if the first one is still pending. This requirement facilitates matching of sends to receives. It guarantees that message-passing code is deterministic, if processes are single-threaded and the wildcard MPI_ANY_SOURCE is not used in receives. (Some of the calls described later, such as MPI_CANCEL or MPI_WAITANY, are additional sources of nondeterminism.) So your example should work fine in all cases. We do use MPI_ANY_SOURCE and MPI_WAITSOME, but even then the first sentence on the sender sequence guarantees correctness (not determinism wrt. to the order to receives from different peers, but that's ok). > 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... It seems that the MPI standard authors had the same feeling. ;) Carsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFNM9Y7RClUBgYbo/kRArp8AJ9Vk6Do34zRqkBT3pYl4W2PQBSh6QCfWkKt 6lxj10ffm0umm0TLDEl1XOU= =JTWA -----END PGP SIGNATURE----- _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
