Should PetscObjectName be collective?

[Barry Smith]

On Nov 17, 2009, at 5:08 PM, Jed Brown wrote:

> Lisandro Dalcin wrote:
>> On Mon, Nov 16, 2009 at 4:04 PM, Barry Smith <bsmith at mcs.anl.gov>  
>> wrote:
>>> Ok, we could just put the "counter" into the MPI attribute and  
>>> then just
>>> have uniqueness of the names within each communicator.  This would  
>>> solve
>>> Jed's problem cleanly.
>>>
>>
>> I agree. +1 on this.
>
> If I understand correctly, every communicator would start at 0 with no
> attempt to distinguish communicators.  PetscObjectName would add an
> attribute to each communicator it sees.
    Nope, don't want to do it this way, it increases the complexity.  
See below.

> Browsing tagm.c,
> MPI_Keyval_free is never called for the other attributes.  This  
> explains
> some valgrind warnings under Open MPI but not under MPICH (presumably
> MPICH frees zombie keyvals in MPI_Finalize() but OMPI does not).

    We should refactor the code to move the body of the code block  
below into  PetscIntialize()
   if (Petsc_Tag_keyval == MPI_KEYVAL_INVALID) {
     ierr =  
MPI_Keyval_create(MPI_NULL_COPY_FN,Petsc_DelTag,&Petsc_Tag_keyval, 
(void*)0);CHKERRQ(ierr);
     ierr =  
MPI_Keyval_create 
(MPI_NULL_COPY_FN,Petsc_DelComm,&Petsc_InnerComm_keyval, 
(void*)0);CHKERRQ(ierr);
     ierr =  
MPI_Keyval_create 
(MPI_NULL_COPY_FN,Petsc_DelComm,&Petsc_OuterComm_keyval, 
(void*)0);CHKERRQ(ierr);
   }
and put a corresponding set of frees() into PetscFinalize().

>  I see
> that Petsc_InnerComm_keyval and Petsc_OuterComm_keyval just uses the
> pointer to hold the value, since the counter changes we need to  
> actually
> malloc.
>
> Do we want the counter to hold a reference count (and be shared across
> MPI_Comm_dup)?

     No, we don't want to share across MPI_Comm_dup(). They are  
different communicators so should have their own name counters. Note  
that it would be rare that there are MPI_Comm_dup()s lying around  
anyways unless the user explicitly calls it.

> This is slightly tricky because it's not normally
> obvious to a user when a duplication occurs, but the numbering would  
> be
> different if the comm was duped before or after the attribute was set
> (unpredictable if it's set in PetscObjectName()).  OTOH,
> PetscCheckSameComm will say duped communicators are equivalent so we
> really have to share the counter.  I'm talking myself into starting a
> reference-counted counter the first time PETSc touches a communicator.

    I am not sure what reference counting you are talking about but  
PETSc currently reference counts how many objects reference a  
communicator attribute (this is tagvalp[1]).  When it gets down to  
zero it deletes the attribute and the inner communicator.

    To get a counter for object names you can increase the size of  
tagvalp[2] to tagvalp[3], then each time you get a name crank the  
value up by 1, much like PetscCommGetNewTag() No need to add new  
attributes.


   Barry

>
>
> Jed
>