[mpiwg-ft] Proposal Feedback

Jim Dinan james.dinan at gmail.com
Sun Feb 23 07:20:00 CST 2014

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.

> (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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20140223/3221fb3e/attachment-0001.html>

More information about the mpiwg-ft mailing list