Open friedmud opened 8 years ago
For a while this can be a compile time switch that we turn on.
--enable-thread-safe-numeric-vectors
?
:+1: for making operator()
actually const
. I have gone from regarding the mutable
keyword as "interesting hack" to "actively evil".
After doing some more thinking about https://github.com/libMesh/libmesh/pull/853 the problem is really that we shouldn't be doing any of the stuff that is happening in
PetscVector::_get_array()
.NumericVector::operator()
isconst
for a reason... and we shouldn't be violating that by usingmutable
(like here: https://github.com/libMesh/libmesh/blob/master/include/numerics/petsc_vector.h#L510 ). That's what's gotten us into this ( https://github.com/idaholab/moose/issues/6436 ) mess.I propose this:
mutable
out ofPetscVector
.virtual void NumericVector::cacheValues()
method that developers can explicitly call in order to allowNumericVectors
to cache local data (i.e. whatPetscVector::_get_array()
is doing). Developers can call this function to speed up subsequentoperator()
calls. This will allow developers the chance to do this explicitly before threaded sections.virtual void NumericVector::restoreCachedValues()
PetscVector::_restore()
should be made to error out in the case thatcacheValues()
has been called... and the data is still cached (i.e. thatrestoreCachedValues()
has not been called).Essentially: I think that we should get much more explicit about the memory movement and caching inside
NumericVector
s.