Prepare CastorDbProducer for concurrent IOVs #24462
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24462/6302 |
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: CalibCalorimetry/CastorCalib @civanch, @arunhep, @tocheng, @cmsbuild, @franzoni, @mdhildreth, @pohsun, @lpernie can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 @wddgit , please, add, at least, minimal description |
|
I edited the description. Hopefully that helps. If you still have questions, let me know. I have a list of something on the order of 20 other ESProducers with similar issues, so you may see other similar pull requests coming in the future. |
|
+1 |
cmsbuild
added
alca-approved
fully-signed
and removed
alca-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
Prior to this PR there was one CastorDbService and the ESProducer held as a data member a shared pointer to this object. This has worked perfectly fine up to now because the Framework has only allowed one IOV to be processed at a time, but we hope in the future to allows multiple IOVs to run concurrently. If there are multiple IOVs being processed concurrently, there must be multiple CastorDbService objects because the contents must be different for different IOVs. In addition, if we want to maximize the concurrency the produce method should be able to run for the different IOVs concurrently and the produce function modifies the CastorDbService. It would create data races for them to work on the same object.
In the modified version, there are multiple CastorDbService objects, one for each concurrent IOV. The ReusableObjectHolder owns and manages those objects in a thread safe manner and replaces the single shared_ptr.
The dependsOn feature of the EventSetup has difficulty communicating which instance CastorDbService a particular callback and produce function are referring to. So the usage of the dependsOn function and its callbacks is replaced by usage of the new ESProductHost class. It has a similar purpose, but works better when there are multiple IOVs because its interface allows direct communication between the produce methods and the lambda function that gets called when the record changes via arguments.