[petsc-dev] Expectations for lock usage in PETSc

[Hovland, Paul]

Dear PETSc developers:

We have a question about the (expected) use of read and write locks in the PETSc implementation of vectors. If one looks at the implementation of VecAXPY in rvector.c (or, really, the implementation of VecAXPYAsync_Private, which is called by VexAXPY), it first calls
      PetscCall(VecSetErrorIfLocked(y, 1));
then calls
      PetscCall(VecLockReadPush(x));
then dispatches the AXPY method, followed by
      PetscCall(VecLockReadPop(x));

We’re curious why it just checks whether y is locked but goes through the whole locking and unlocking process for x. It seems like one should either also lock y or one could simply check whether there is a write lock on x, without having to go through the whole push/pop sequence.

Is it written this way because the easiest way to check whether x has a write lock on it (and throw an error if it does)  is to call VecLockReadPush? Is this pattern a relic of when PETSc implemented locks differently? Is there some other reason for the “inconsistent” (to our minds) handling of x and y?

Thanks,

Paul & Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250908/4fdec15f/attachment.html>