<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Nov 2021 at 19:26, Joseph Schuchart <<a href="mailto:schuchart@icl.utk.edu">schuchart@icl.utk.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Lisandro, All,<br>
<br>
(Lisandro: Apologies if you receive multiple copies, I wasn't sure <br>
whether you're on the list)<br>
<br>
I have some thoughts as a follow-up to the discussion yesterday on <br>
exposing reference-counts of MPI objects to the user. First, let me try <br>
to summarize the use-case: for a developer in a language that supports <br>
ref-counting, it is hard to write ref-counted wrapper objects around MPI <br>
handles *and* be able to pass the handle to third-party libraries <br>
written in languages that do not support whatever ref-counting mechanism <br>
is used (e.g., a wrapper around MPI_Comm in python, passing the handle <br>
to a C library's set_comm() function). </blockquote><div><br></div><div>Yes, </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The idea is that exposing a <br>
reference counting mechanism in MPI to the user would help here because <br>
that is the lowest common denominator shared by all libraries. Is that <br>
correct? (I missed the first couple of minutes, just want to make sure I <br>
get it right)<br>
<br></blockquote><div><br></div><div>but I would add that adding facilities for better handling the lifetime of handles (at least for some types) is not only useful for ref-counted languages like Python, but even for C/C++/Fortran libraries.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The problem now is that passing the handle out of the ref-counted <br>
wrapper to a library potentially creates dangling references because <br>
that library might store the handle and eventually free it without the <br>
wrapper knowing. Bummer.<br></blockquote><div><br></div><div>Or not free it, and then the library caller is responsible for keeping track of the handle and destroying it at a later time.</div><div>MPI provides no clear recommendation, much less proper APIs, for sane handling of MPI object lifetimes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Here is where I am not sure how ref-counting at the MPI library level <br>
would help: how would you know whether the library's set_comm() call <br>
actually increments the ref-count? </blockquote><div><br></div><div>Right now, you don't. You don't know if the library will ever free the handle, ever. The "contract" has to be written in the library documentation, and there are no general guidelines in the MPI standard. So library developers do whatever they like or think it is the right thing to do (if they ever think about the issue)... and we scientists are terrific software engineers ;-) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just as you cannot be sure that it <br>
won't destroy the MPI object and leave your handle dangling, you have no <br>
guarantee that the ref-counting would be correct because there is no way <br>
to enforce that across all supported languages.<br></blockquote><div><br></div><div>Indeed. Just adding the APIs is not enough. The standard should add new recommendations.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As Dan had pointed out, duplicating MPI objects is the right way to go <br>
here.</blockquote><div><br></div><div>Ask PETSc folks about the messy code they have in place to prevent excessive communicator duplication. They basically had to add their own refcounting for MPI_Comm using attributes, inner comm dupes, etc. So, no, duplication is not always the answer.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It is good practice for libraries to treat handles to MPI objects <br>
as borrowed references and only store handles to duplicates.</blockquote><div><br></div><div>Alternatively, with my proposal/request, libraries could take ownership of a reference.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Unless <br>
explicitly documented that ownership is transferred, the library should <br>
not destroy the MPI object it received.</blockquote><div><br></div><div>And then the burden on managing handle lifetime is put on the library caller.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Yes, there is no way to enforce <br>
this in C, so it has to be part of the verbal API contract. But the same <br>
would be true for correct reference counting. I don't see a way around <br>
relying on soft contracts here...<br></blockquote><div><br></div><div>All I'm asking for is the addition of a few APIs [for example, MPI_Type_clone(datatype, &newref)  or perhaps MPI_Type_incref(datatype), and so on for other types] that would help to better define SOFT contracts.</div><div><br></div><div>This is all about soft contracts, there is no way to enforce anything in C.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And as was discussed during the call: MPI libraries may ref-count <br>
internal parts of communicators and datatypes so their duplication <br>
should be fairly lightweight.</blockquote><div><br></div><div>Except that duplication is not the same as aliasing, and users/libraries may have valid reasons to want to use aliasing. </div><div>For the case of mpi4py, it is all about being a wrapper as thin as possible. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I realize that there are no duplication <br>
functions for files and windows (I had proposed window duplication at <br>
EuroMPI this year; I'm not what sure the semantics for files would be <br>
though). Would having window and file duplication help here?<br></blockquote><div><br></div><div>How would window duplication work? The Win handle refers to the same memory buffer, then you can attach different attributes on each duplicate? I'm not sure how that behaviour would be useful, although I'm not against it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Or did I get any of the discussion wrong?<br></blockquote><div><br></div><div>I think you got it just right. However, I still disagree that duplication is the ultimate solution.</div><div><br></div><div>I believe this whole subject is already controversial enough. Perhaps we can start with other related things that would be less controversial.</div><div>For example, relaxing MPI_XXX_Free rules such that the following snippets of code do not error as they currently do:</div><div><br></div><div>datatype = MPI_INT;</div><div>MPI_Type_free(&datatype); // freeing built-in</div><div><div>datatype = MPI_DATYPE_NULL;</div><div>MPI_Type_free(&datatype); // freeing NULL</div><div><div><br></div></div><div>and similarly for MPI_Op, MPI_Group, MPI_Info.</div><div>I'm not sure about Comm, Win, File, but at least freeing the NULL handles should not error.</div><div>This is just a relaxation of current rules, so it is backward compatible.</div><div></div></div><div><br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Lisandro Dalcin<br>============<br>Senior Research Scientist<br>Extreme Computing Research Center (ECRC)<br>King Abdullah University of Science and Technology (KAUST)<br><a href="http://ecrc.kaust.edu.sa/" target="_blank">http://ecrc.kaust.edu.sa/</a><br></div></div></div></div>