LArHV: Thread-safety cleanups.
Compare changes
The HV manager classes here mix together two kinds of information. There is information about the structure of the cells, which is static, and information about the actual HV settings, which derives from conditions data and can change.
The managers are stored in the detector store. As originally intended, the manager classes get updated in place when conditions change. The actual update of the HV data is done lazily through const methods called by the accessors. This is not thread-friendly. Though earlier changes ameliorated the worst of the issues, it's still difficult to ensure that there can't be problems (and it is problematic to get the thread-safety checker to accept the code).
Here, we rework these classes to put these issues to rest. The conditions information is firmly separated from the geometry information. The geometry information remains part of the manager classes, while the HV information is computed on request and returned in a separate structure. The inputs for this are the required conditions data objects.
For compatibility with previous usage, we also continue to support constructing HV information with no explicit inputs. This will use the obsolete LArCablingTool rather than the HV mapping conditions object, so these methods are tagged as not thread-safe. The clients for this at this time are the G4 initialization classes, which don't have the conditions objects available.
LArCondUtils, LArG4Barrel, LArG4EC, LArG4FCAL, LArG4HEC, CaloCondPhysAlgs, VP1CaloReadoutSystems:
Update LArHV2Ntuple and LArHVPathologyDBAlg for change in the LAr HV manager classes. Now, we need to explicitly request the calculation of HV information from conditions data; this information is returned in a separate structure.
LArRecUtils: Update for LAr HV manager changes.
LArHVManager::reset() has been removed.