February 2011 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Matthew Knepley 15 Feb '11

15 Feb '11

On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to > set the pointer explicitly to 0 after the object is destroyed. > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too > unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > Was this a bad design decision? Should it be revisited? > > > > Barry > > > > Two use cases > > > > 1) error detection when someone tries to reuse a freed object > > > > We catch this with other error detection. I do not think we would gain > much here. > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible > that MatMutl() will crash while looking around inside where mat points. If > MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of > if (!mat) nice error message. I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider double-free a recoverable error, so a SEGV is alright here as well. Matt > > Barry > > > > > 2) when removing some objects from a data structure that will be used > data one currently needs to do > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > True, but again I do not think the win is large. > > > > Matt > > > > -- > > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

This also applies to PetscFree() On Feb 15, 2011, at 4:47 PM, Barry Smith wrote: > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > Was this a bad design decision? Should it be revisited? > > Barry > > Two use cases > > 1) error detection when someone tries to reuse a freed object > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr);

1 0

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > Was this a bad design decision? Should it be revisited? > > Barry > > Two use cases > > 1) error detection when someone tries to reuse a freed object > > We catch this with other error detection. I do not think we would gain much here. No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message. Barry > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > True, but again I do not think the win is large. > > Matt > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener

1 0

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Lisandro Dalcin 15 Feb '11

15 Feb '11

On 15 February 2011 19:47, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > Was this a bad design decision? Should it be revisited? > This is what I needed in petsc4py, so I had to write my own wrapper routines: http://code.google.com/p/petsc4py/source/browse/src/PETSc/petscobj.pxi#35 > Barry > > Two use cases > > 1) error detection when someone tries to reuse a freed object > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > I think (2) is the more compelling use case... -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Matthew Knepley 15 Feb '11

15 Feb '11

On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to > set the pointer explicitly to 0 after the object is destroyed. > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too > unnatural to me in 1994) thus not allowing 0ing the pointer. > > Was this a bad design decision? Should it be revisited? > > Barry > > Two use cases > > 1) error detection when someone tries to reuse a freed object > We catch this with other error detection. I do not think we would gain much here. > 2) when removing some objects from a data structure that will be used data > one currently needs to do > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); True, but again I do not think the win is large. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. Was this a bad design decision? Should it be revisited? Barry Two use cases 1) error detection when someone tries to reuse a freed object 2) when removing some objects from a data structure that will be used data one currently needs to do XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr);

1 0

Re: [petsc-dev] [petsc-maint #64229] Re: PetscExceptionTry1
by Jed Brown 14 Feb '11

14 Feb '11

On Mon, Feb 14, 2011 at 21:15, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Insane :-( Sanity does not seem to be a trait valued by many people who write software.

1 0

Re: [petsc-dev] [petsc-maint #64229] Re: PetscExceptionTry1
by Barry Smith 14 Feb '11

14 Feb '11

On Feb 14, 2011, at 2:14 PM, Jed Brown wrote: > On Mon, Feb 14, 2011 at 21:12, Jed Brown <jed(a)59a2.org> wrote: > >> somehow otherwise communicating through the file system > > > Maybe running PETSc on a subcomm with some proprietary or high-inertia code > on a different communicator? IIRC, there are some climate models that > "couple" using the file system. Insane :-( > > On Mon, Feb 14, 2011 at 21:12, Jed Brown <jed(a)59a2.org> wrote: > somehow otherwise communicating through the file system > > Maybe running PETSc on a subcomm with some proprietary or high-inertia code on a different communicator? IIRC, there are some climate models that "couple" using the file system.

1 0

Re: [petsc-dev] PetscExceptionTry1
by Jed Brown 14 Feb '11

14 Feb '11

On Mon, Feb 14, 2011 at 21:12, Jed Brown <jed(a)59a2.org> wrote: > somehow otherwise communicating through the file system Maybe running PETSc on a subcomm with some proprietary or high-inertia code on a different communicator? IIRC, there are some climate models that "couple" using the file system.

1 0

Re: [petsc-dev] PetscExceptionTry1
by Jed Brown 14 Feb '11

14 Feb '11

On Mon, Feb 14, 2011 at 21:05, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Then we need a PetscFOpen() to be able to return a flag indicating that it > cannot open the file. > > But I don't think it is right to call it a "race condition", it is just a > non-atomic operation and it is possible that after the test succeeds the > open may fail. But I don't think we should be using algorithms/approaches > that rely on checking that a file exists and opening it be an atomic > operation we don't use the filesystem in such a dynamic way so I think > checking then opening is fine for PETSc. > The question is whether any users that we care to support may have multiple processes trying to open the same file or somehow otherwise communicating through the file system. At the moment, I can't think of a use case where it is important.

1 0