On Feb 23, 2014, at 7:20 AM, Jim Dinan <[email protected]> wrote:
Hi Aurelien,
(1) Are the semantics for the MPI probe operations (probe, iprobe, mprobe) well defined? Including when MPI_ANY_SOURCE is used?
Yes, they are exactly the same as for normal recv operations. We had a WG phone call issue on mprobe alone, sometime last september, to verify that it was not problematic.
We state that non-blocking operations must not raise an error when they are initiated. We may need an exception to this rule for MPI_Iprobe to state that it has MPI_Test semantics. An Iprobe could be polling with MPI_ANY_SOURCE and lead to deadlock if it does not return an error.
Hmm, that’s a good point. I guess the probe functions wouldn’t be covered under the text about the completion functions. I guess we do need to add text here. It’s inside the two week deadline so I’m not sure what the right thing to do here would be.
(2) For comm_shrink, what happens when the remote group in an intercommunicator becomes empty? Is it valid to get back an intercommunicator with an empty remote group? That’s a pretty bizarre case. It is to be noted that the semantic for the shrink is well defined: the outcome is the same as if the user had called split with colors set to MPI_UNDEFINED at all remote group processes. From the definition of SPLIT stated page 247, the well defined outcome is that MPI_COMM_NULL is returned when a color is used on only one side of the intercomm.
Ok, thanks! Just wanted to make sure that this was defined.
(3) In 15.2 (pg. 594:21), can we replace the sentence "always complete in a finite amount of time" with the simpler "eventually complete”? I believe the original formulation carries the argument more visibly by being pedantic; but if you feel strongly about it, I don't.
The wording isn't incorrect, this is just word smithing. Strong words "always" and "finite" imply something about when a thing will occur, when in fact the semantic is not any stronger than "eventually". "Eventually" is used for semantics like this in the RMA chapter.
~Jim. _______________________________________________ mpiwg-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft