[petsc-dev] Removing VecGetArrayPrivate3
Barry Smith
bsmith at mcs.anl.gov
Wed Nov 24 16:18:59 CST 2010
On Nov 24, 2010, at 3:51 PM, Jed Brown wrote:
> I thought the purpose of this function was to avoid calling VecGetArray multiple times on identical arguments.
Yes, that was the purpose.
> In particular, consider a Vec implementation that was not backed by a contiguous array. Must these implementations keep a reference count of how many times the same array was checked out?
Presumably. Or we could pull the reference counting up into the base method and only call the VecGet/RestoreArray[Read]() method the first/last time so that each implementation does not need to manage it. For "standard" PETSc vectors the counting is not needed except for checking that the user has done things correctly.
> This violates the present API implied by VecGetArray_Seq:
>
> if (vin->array_gotten) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ORDER,"Array has already been gotten for this vector,you may\nhave forgotten a call to VecRestoreArray()");
This particular piece of code should not normally (ever) be triggered. Do you have code where this error is generated? Please let me know where. Eventually this check will be tossed.
>
> Do you want to relax this restriction on the API (placing extra burden on the implementation), or revert the patch?
The current model (which does not have code to check if it is violated, except for the code fragment above you found) is that multiple VecGetArrayRead() reads can be done on the same Vec but only a single VecGetArray[Write](). A write can be called on a Vec that has an open VecGetArrayRead(). After the VecRestoreArray[Write]() is called the values are copied back to their original location, when all reads and writes are closed the array can be freed. Restoring the Write array results in an increase in the Vec state.
All those VecGetArrayPrivateXXX() stuff was too complicated and messy, I did not like it. Hideously complicated crap for something very simple.
Please let me know specific concerns you have with the "new" model so I can make sure that everything works.
Barry
>
> Jed
More information about the petsc-dev
mailing list