[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.
~Jim.
-------------- 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