<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Feb 23, 2014, at 7:20 AM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><div dir="ltr">Hi Aurelien,<div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">> (1) Are the semantics for the MPI probe operations (probe, iprobe, mprobe) well defined?  Including when MPI_ANY_SOURCE is used?<br>
><br>
</div>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.</blockquote><div><br></div><div><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> (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?<br>

</div>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.</blockquote>
<div><br></div><div>Ok, thanks!  Just wanted to make sure that this was defined.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">> (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”?<br>
</div>I believe the original formulation carries the argument more visibly by being pedantic; but if you feel strongly about it, I don't.</blockquote><div><br></div><div>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.</div>
<div><br></div><div> ~Jim.</div></div></div></div>
_______________________________________________<br>mpiwg-ft mailing list<br><a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft</blockquote></div><br></body></html>