On 8/6/07, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote:
> > Because many predefined, intrinsic objects cannot (or should not be
> > able to) be freed, acording to the standard.
> I understand that. :-) But why would you call XXX.Free() on an
> intrinsic object? If you're instantiating an MPI handle, you know
> that it's a user-created object and therefore you should MPI free it,
> right? If you didn't instantiate it, then it's not a user-defined
> object, and therefore you shouldn't MPI free it.
Well, let take two examples:
- GROUP_EMPTY is predefined handle. The standard says that some group
operations may return ir (for example, Group::Excl). So you get a
handle which may (or may not) be GROUP_EMPTY. Then you are going to
free the return of Group::Excl(). If it is an empty group, but not
equal (in the C == operator sense) to GROUP_EMPTY, then you can safely
free it, but if the return is exactly GROUP_EMPTY. what should I do as
I user? Should I free it? Well, the standard says nothing about this,
and MPI implementations can do what they want. Disccussing this issue
with MPICH2 developers, they first decided to generate an error if
Group::Free() is called with GROUP_EMPTY, then I updated my code,
released a new version of mpi4py, and after all this, they sent me a
mail saying they reverted the change (i.e, users can free GROUP_EMPTY)
because some extenal code (Intel MPI Benchmark) was failing. And take
into account that checking for GROUP_EMPTY is a easy task (just use
==), but even in that case it you do not know if you can safely free
the result of a group operation.
- Other example is File::Get_view(). This function returns datatype
handles. If the returned handle is predefined, you cannot free it (not
sure, but i believe the standars explicitely says that), if it is not,
you sould free it. But in order to know that, you have to go through
IMHO, all those issues could be corrected in the standard, as follow
- Group operations NEVER return GROUP_EMPTY, so the user is in charge
to always call Group::Free() on the result. GROUP_EMPTY cannot be
freed, and it is just provided by convenience (i.e. you can use
Group::Compare() to know if a group has no members). The performance
implications of doing this (that is return a true duplicate of the
empty group) seems negligible.
- File::Get_View() should also never return a predefined datatype, but
a duplicate of them (in the Datatype::Dup() sense). Again, I cannot
see any performance penalty on this.
> If it's a question of trying to have a generic destructor (pardon me
> -- I know next to nothing about python) for your MPI handle classes,
> you can have a private member flag in your handle class indicating
> whether the underlying MPI handle is intrinsic or not. Have a
> special communicator for instantiating the global / intrinsic objects
> (e.g., for MPI_INT) that sets this flag for "true"; have all other
> constructors set it to "false". In the destructor, you check this
> flag and know whether you should call the corresponding MPI free
> function (assuming you solve issues surrounding deadlock, etc.).
I am currently doing this, but only for issuing a warning if a
non-predefined object is 'leaked'. For all local objects, like groups,
datatypes, I believe I could go further and enable automatic
destruction, but for global objects, like comm, win, files, the
deadlock problem is almost impossible to avoid. So for global objects
the user is still in charge of doing de destruction. But I am
completely fine with this. The only big problem is always to know (in
a implementation independed way) if you are able to free a handle.
Please, let continue this thread!!! We need to agree in the way things
should be done, and surely we should include MPICH2 people in this
discussion. This way, we have more chances to correct/clarify things
por MPI-2.1 (or even MPI 2.0).
Or do you think I should raise all this stuff to mpi-2.1 mailing list?
Regarding the archives, the list does not seems to be really active.
That's the reason I am always shotting here (and on mpich-maint) with
the hope of attract the attention of experienced people like all you
(in the end, I was in high-school by the time MPI was borned!!).
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina