Currently 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 ReadHandleKeyArrayProperty instance.
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.