Refactored ProductHolders #13698
Merged
Refactored ProductHolders #13698
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By removing the base class into its own header file we reduce coupling to the different implementations of the inheriting classes.
ScheduledProductHolder and SourceProductHolder were identical except for their default status. Consolidated the two into PuttableProductHolder which is passed the default status at constructor time.
There methods of InputProductHolder were only used by the class itself so they were made private.
Removed the explicit empty destructors for all ProductHolders since the default one is sufficient. Removed the mergeProduct taking two arguments since it is never called.
ProductData is no longer a class used outside of the internals of Principal.
Non of the other ProductHolders were caching their calculations of availability so this was removed to allow greater uniformity.
DataManagingProductHolder is now the only class which directly owns the ProductData and keeps track of the status.
All concrete implementations of ProductHolderBase::putProduct which took ProductProvenance as an argument always ignored the provenance. This is because provenance handling isn't done by the ProductHolders anymore. Therefore all calls to putProduct now just pass the Wrapper.
Renamed the function to attempt to better described what the function does.
Use the status information to decide if the data product should be retrieved from storage or to run an unscheduled producer. All code that changes the Wrapper pointer now also has to update the status. The only exception is how ProductHolders work in SubProcesses (which will be fixed in a later commit)
Instead of partially sharing internal ProductHolder data between the Principals of the parent process and the SubProcess, we now use a ParentProcessProductHolder in the SubProcess Principal which calls back to the parent process' ProductHolder.
Only the ParentProcessProductHolder needs a working connectTo method.
Changed connectTo in ProductHolderBase to get the Principal from the parent process. This is needed if an unscheduled execution from the parent is delayed until a call in a SubProcess.
The check that a WrapperBase passed to the Principal is unique was not thread safe. In addition, the framework always creates new wrappers when a EDProducer puts a product. Therefore only a source could make this mistake.
In order to avoid having the base class ProductHolderBase have direct access to the product (which could lead to threading problems) the merging of data products from the same branch is now handled by the inheriting classes.
For thread safety, the status of the product must be checked before accessing the product since the status operates as the synchronizer. Providing direct access to the product from the base class makes it too easy to miss the checks on the status. Now only the internals of the inheriting classes have access to the product directly. All other access must go through resolveProduct.
The method is only needed by the class and classes which inherit from it.
Several of the ProductStatus enumerations were designating nearly the same status. These were consolidated to share the same status.
…uctImpl The majority of the code for resolveProduct_ was in common between the different inheriting classes. This was moved to a common function of the base class.
The productUnavailable_ method was moved to the DataManagingProductHolder base class since the function could be made the same for all inheriting classes. onDemandWasNotRun was renamed to unscheduledWasNotRun to better match the naming convention of the framework.
Since all the versions of mergeProduct_ from classes that inherit from DataManagingProductHolder could be made identical, the implementation was moved to the base class. This was also the last place outside of DataManagingProductHolder which called getProductData so that function could now be made private.
The ProductHolder classes which forward requests to other ProductHolders should never have their methods which put or merge data called.
Instead of having the Principal calling several ProductHolder functions in order to decide if a product should be put or merged, the logic was moved to be internal to the ProductHolder.
Previously, just before each call to ProductHolderBase::put or putAndMerge there was a call to ProductHolderBase::checkType. The call was moved to be inside the functions instead.
Only the inheriting class needs to be able to call checkType.
By moving the putOrMergeProduct logic into DataManagingProductHolder it is possible to reduce the number of virtual functions from the base class which are not callable from the ProductHolders which forward calls to other ProductHolders.
Only the class DataManagingProductHolder now called throwProductDeletedException so the function was moved to that class.
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_8_1_X. It involves the following packages: DataFormats/Common @cmsbuild, @smuzaffar, @Dr15Jones, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
|
please test |
|
The tests are being triggered in jenkins. |
|
-1 Tested at: 5f527a4 ---> test runtestTqafTopEventSelection had ERRORS you can see the results of the tests here: |
|
Test failures are unrelated to this pull request. |
|
+1 |
cmsbuild
added
core-approved
fully-signed
and removed
core-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (but tests are reportedly failing). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactored the ProductHolder class as a first step towards allowing multiple threads to be used on one event.