Should PetscObjectName be collective?

[Jed Brown]

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.  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).  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)?  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.


Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091118/dd59f2ab/attachment.sig>