Depending on the use-case you may also find PetscObjectRegisterDestroy() useful. If you can’t guarantee your PetscObjectDestroy() calls are collective, but have some other collective section you may call it then to punt the destruction of your object to PetscFinalize() which is guaranteed to be collective.
https://petsc.org/main/docs/manualpages/Sys/PetscObjectRegisterDestroy.html <https://petsc.org/main/docs/manualpages/Sys/PetscObjectRegisterDestroy.html> Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Oct 22, 2021, at 23:33, Jed Brown <[email protected]> wrote: > > Junchao Zhang <[email protected] <mailto:[email protected]>> > writes: > >> On Fri, Oct 22, 2021 at 9:13 PM Barry Smith <[email protected]> wrote: >> >>> >>> One technical reason is that PetscHeaderDestroy_Private() may call >>> PetscCommDestroy() which may call MPI_Comm_free() which is defined by the >>> standard to be collective. Though PETSc tries to limit its use of new MPI >>> communicators (for example generally many objects shared the same >>> communicator) if we did not free those we no longer need when destroying >>> objects we could run out. >>> >> PetscCommDestroy() might call MPI_Comm_free() , but it is very unlikely. >> Petsc uses reference counting on communicators, so in PetscCommDestroy(), >> it likely just decreases the count. In other words, PetscCommDestroy() is >> cheap and in effect not collective. > > Unless it's the last reference to a given communicator, which is a > risky/difficult thing for a user to guarantee and the consequences are > potentially dire (deadlock being way worse than a crash) when the user's > intent is to relax ordering for destruction. > > Alberto, what is the use case in which deterministic destruction is > problematic? If you relax it for individual objects, is there a place you can > be collective to collect any stale communicators?
