IPileUpTool implementations can be called using ReadHandleKeys to read containers from a single
StoreGateSvc instance (for Overlay and digitization without pile-up) and using just the container name to access multiple instances of each input container from multiple random
StoreGateSvc instance (for pile-up digitization).
When pile-up digitization is run in AthenaMT, the tools are cloned per thread, as they are not currently reentrant.
It looks like the cloning procedure is as follows:
- create a new default tool instance
- take the set of property names to override from their defaults from the configuration
- obtain the property value from the initialized tool (not necessarily the values set the configuration)
- use those to set the properties of the cloned tool.
This works if the values of properties are not updated during
initialize(), but calls of the form
ReadHandleKeyArrayProperty.initialize(false) call violate this, by clearing the contents of the
This merge request works around the issue for
TileHitVecToCntTool by using a regular
StringArrayProperty for the input container names and using that to populate a
ReadHandleKeyArray member variable during
initialize(). This should mean that the data dependencies of the PileUpTools are correctly determined still.
LArPileUpTool does not show the issue as the
ReadHandleKeyArray properties are not set in the configuration (this seems to be sufficient to avoid it), but have made the same C++ changes for robustness.
This addresses ATLASSIM-6382.