<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>I'll reply more to jeff Gannon when I'm not on a phone - can't reply inline easily...</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Jim: yes, it says the current value - but of what? The hint? Because if it's the current value of *the hint*, I'd argue that that's the input from the user. </div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Further, I'd claim that the implementation cannot change the value of the hint - it can only choose what to do with a given hint. Specifically: *What the implementation chose to do with a hint* is a different value (i.e., an output
value, which may be more suitable to MPI-t). </div>
<div id="AppleMailSignature"><br>
Sent from my phone. No type good. </div>
<div><br>
On Feb 16, 2016, at 3:05 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">The text says that the "current setting" is returned, not the setting requested in a previous operation that set info on the communicator. It is not specified whether #2 or #3 should occur, but as long as "no" is the default value of the info
key in question, the value of the setting is still unambiguously (if inconveniently) conveyed to the user.
<div><br>
</div>
<div> ~Jim.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 16, 2016 at 9:50 AM, Jeff Squyres (jsquyres)
<span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jim --<br>
<br>
Based on your answer, I'm now a bit confused. I now need to back up from my original question and clarify what MPI_COMM_INFO_GET is supposed to return in this scenario:<br>
<span class=""><br>
-----<br>
MPI_Info_set(myinfo, "use_shared_memory", "yes"); <br>
MPI_Comm_set_info(comm, my info);<br>
</span>// MPI implementation recognizes the "use_shared_memory" hint, but is<br>
// unable to use shared memory with this communicator<br>
MPI_Comm_get_info(comm, myinfo_returned); <br>
-----<br>
<br>
What value is in myinfo_returned for use_shared_memory?<br>
<br>
MPI 3.1 6.4.4 p250 says:<br>
<br>
"MPI_COMM_GET_INFO returns a new info object containing the hints of the communicator associated with comm. The current setting of all hints actually used by the system related to this communicator is returned in info_used."<br>
<br>
"...all hints actually used by the system..." is actually a bit ambiguous.<br>
<br>
In this case, "use_shared_memory" is *recognized* by the MPI implementation. But it wasn't able to be *used* (e.g., because no shared memory was available). So is the value in info_used supposed to be:<br>
<br>
1. The user's requested hint (i.e., "yes"), or<br>
2. What MPI is actually using (i.e., "no"), or<br>
3. Since this hint wasn't "used" by the system, then the "use_shared_memory" key shouldn't be returned in info_used<br>
<br>
?<br>
<br>
Indeed, one could make the argument that MPI_COMM_GET_INFO is supposed to return exactly the value(s) that the user requested (if it is *recognized* by the implementation), and MPI_T pvars and/or cvars should be queried to obtain the values indicating what
the implementation chose to do with those hints.<br>
<br>
Thoughts?<br>
<span class="im HOEnZb"><br>
<br>
<br>
On February 15, 2016 at 8:25:44 PM, Jim Dinan (<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>) wrote:<br>
> "Same" should mean that these call sequences produce the same newcomm,<br>
> right?<br>
><br>
> MPI_Comm_get_info(comm, myinfo_returned);<br>
> MPI_Comm_dup_with_info(comm, &newcomm, myinfo_returned);<br>
><br>
> and<br>
><br>
> MPI_Comm_dup(comm, &newcomm);<br>
><br>
> I think this is an argument for "no".<br>
><br>
> I'm not sure if the question is asking whether the MPI implementation can<br>
> change communicator info values dynamically. I'm not sure the spec<br>
> actually addresses that possibility. If this is allowed, newcomm would<br>
> still only get "yes" if the implementation had also toggled the info key on<br>
> the parent communicator.<br>
><br>
> ~Jim.<br>
><br>
</span>
<div class="HOEnZb">
<div class="h5">> On Mon, Feb 15, 2016 at 5:34 PM, Jeff Squyres (jsquyres) > > wrote:<br>
><br>
> > This question has come up in the Open MPI community:<br>
> ><br>
> > -----<br>
> > MPI_Info_set(myinfo, "use_shared_memory", "yes");<br>
> > MPI_Comm_set_info(comm, myinfo);<br>
> > MPI_Comm_get_info(comm, myinfo_returned);<br>
> > // Assume here that there was not enough shared memory available to use<br>
> > shared-memory for<br>
> > // communication on this comm, so MPI_Info_get() tells us that<br>
> > use_shared_memory is "no".<br>
> ><br>
> > // ...time passes, and now assume there is more shared-memory available<br>
> > MPI_Comm_dup_with_info(comm, &newcom);<br>
> > MPI_comm_get_info(newcom, myinfo_returned);<br>
> > -----<br>
> ><br>
> > Should newcom have "use_shared_memory" set to "yes" or "no"?<br>
> ><br>
> > Arguments for "yes":<br>
> > - the user originally asked for "yes"<br>
> > - now there is shared memory available<br>
> ><br>
> > Arguments for "no":<br>
> > - the current value for "used_shared_memory" on the parent communicator is<br>
> > "no"<br>
> ><br>
> > Which should it be?<br>
> ><br>
> > MPI-3.1 6.4.2 p238 says:<br>
> ><br>
> > "...Returns in newcomer a new communicator with the same group or groups,<br>
> > same topology, same info hints, any copied cached information, but a new<br>
> > context (see Section 6.7.1)."<br>
> ><br>
> > So the specific question here is: what exactly does "Same info hints"<br>
> > mean? The user-specific hint, or the current value of the hint?<br>
> ><br>
> > --<br>
> > Jeff Squyres<br>
> > <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
> > For corporate legal information go to:<br>
> > <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">
http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
> > _______________________________________________<br>
> > mpi-forum mailing list<br>
> > <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
<br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">
http://www.cisco.com/web/about/doing_business/legal/cri/</a></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</body>
</html>