[petsc-dev] Expectations for lock usage in PETSc

[Satish Balay]

I see the initial change was at:

https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/d9ca1df42eda25bc875149d6d493aad6e204c9ff__;!!G_uCfscf7eWS!axSTcfB_iW7kKJe0hb14ApkNvXzHZBDqzONfz8eP0TVZNPqaBKoS2fxZhoUWUBKQk8RQpEVrly41e_Pt-04eizfoQw$ 

And then refined at:

https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/8860a1345bb13588f3290163e72ce904901dbfb9__;!!G_uCfscf7eWS!axSTcfB_iW7kKJe0hb14ApkNvXzHZBDqzONfz8eP0TVZNPqaBKoS2fxZhoUWUBKQk8RQpEVrly41e_Pt-04ysS1gxw$ 

Satish

On Mon, 8 Sep 2025, Hovland, Paul via petsc-dev wrote:

> 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
>