[mpich2-dev] some comments on attribute catching, create/free() keyvals and all that.

[Dave Goodell]

Lisandro,

Before I sent my last mail I did run your code example with the latest  
SVN trunk version of MPICH2 and it ran just fine.  Was I supposed to  
get a crash, segfault, warning, or something else?  Your email was not  
clear in this regard.

I believe that the problem you are trying to describe was fixed in  
r4029 [1].

Or are you trying to point out that you get back the same value for  
Key2 that you were previously assigned for Key1 before you freed Key1?

 From your first email:
>>> Should MPICH2 stop decrefing the keyval counter? You know, about  
>>> 2<<31
>>> values should be enough, right ;-) ?

We don't actually assign these values from the entire space of  
integers.  They are MPICH2 handle values which are allocated in a  
fashion similar to malloc/free (but not using malloc/free).  However,  
discussion of details of MPICH2 handle values is beyond the scope of  
this email.  The main takeaway from this fact though is that you don't  
actually have 2**32 values available in the MPICH2 implementation *by  
design*.

>>> But then.. What the pourpose of having MPI_Keyval_free()? Just to
>>> invalidate de passed value by setting it to KEYVAL_INVALID?

The point of MPI_Keyval_free is to permit the MPI implementation to  
reclaim any resources (usually just memory) associated with the  
attribute keyval.  However, as the MPI Standard points out, the  
implementation cannot actually free the keyval itself until there are  
no other references to it (in the form of attribute values).

-Dave

[1] https://trac.mcs.anl.gov/projects/mpich2/changeset/4029

On Mar 13, 2009, at 1:34 PM, Lisandro Dalcin wrote:

> Dave, this is not related at all with the ticket... but with a
> behavior of MPICH2 (and likely others MPI's out there, just confirmed
> this on Open MPI) about how create()/free() keyvals work...
>
> Please, try to read my mail and run the code example... I would lilke
> to know your opinions about this behaviour, this could be really
> dangerous :-)
>
>
> On Fri, Mar 13, 2009 at 4:14 PM, Dave Goodell <goodell at mcs.anl.gov>  
> wrote:
>> Lisandro,
>>
>> Have you seen our recent commits on this issue?  I believe that the  
>> issues
>> you pointed out were resolved in the following changesets: r4025- 
>> r4030,
>> r4044, r4048.
>>
>> Related trac tickets: #222, #449
>>
>> -Dave
>>
>> On Mar 13, 2009, at 1:01 PM, Lisandro Dalcin wrote:
>>
>>> As I've shown in a previous emal, MPICH2 likely implement
>>> create()/free() for keyvals using a counter that is incr/decr ...
>>>
>>> Now, give a try to the code pasted below. This shows that (at  
>>> least in
>>> MPICH2), MPI_Keyval_free() have to be used with great care as it is
>>> IMHO dangerous, and basically these calls should be all done near
>>> MPI_Finalize() time... or bad things could happen...
>>>
>>> The only reference I can found in the MPI standard is at
>>> (http://www.mpi-forum.org/docs/mpi21-report-bw/node147.htm#Node147)
>>> where MPI_Comm_free_keyval() is explained... However, I believe that
>>> description is talking about different things...
>>>
>>> Should MPICH2 stop decrefing the keyval counter? You know, about  
>>> 2<<31
>>> values should be enough, right ;-) ?
>>> But then.. What the pourpose of having MPI_Keyval_free()? Just to
>>> invalidate de passed value by setting it to KEYVAL_INVALID?
>>>
>>>
>>> #include <mpi.h>
>>> #include <stdio.h>
>>>
>>> int free_KeyVal(MPI_Comm c, int k, void *v,void *ctx)
>>> {
>>>  printf("free_KeyVal()\n");
>>>  return MPI_SUCCESS;
>>> }
>>>
>>> int main( int argc, char ** argv ) {
>>>  int Key1, Key2, Val1=1, Val2=2, ValOut;
>>>  MPI_Init(&argc, &argv);
>>>
>>>  MPI_Keyval_create(MPI_NULL_COPY_FN, free_KeyVal, &Key1,(void *) 0);
>>>  MPI_Attr_put(MPI_COMM_SELF, Key1, &Val1);
>>>  MPI_Keyval_free(&Key1);
>>>
>>>  MPI_Keyval_create(MPI_NULL_COPY_FN, MPI_NULL_DELETE_FN, &Key2, 
>>> (void *)
>>> 0);
>>>  MPI_Attr_put(MPI_COMM_SELF, Key2, &Val2);
>>>  MPI_Keyval_free(&Key2);
>>>
>>>  MPI_Finalize();
>>>
>>>  return 0;
>>> }
>>>
>>>
>>> --
>>> Lisandro Dalcín
>>> ---------------
>>> 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
>>> Tel/Fax: +54-(0)342-451.1594
>>
>>
>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> 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
> Tel/Fax: +54-(0)342-451.1594