-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix uploading EventSetup conditions from multiple CUDA streams [11.3.x] #34731
Fix uploading EventSetup conditions from multiple CUDA streams [11.3.x] #34731
Conversation
When multiple CUDA streams are trying to initialise the same EventSetup object, the first one to do so starts the asynchronous operations, and the others are supposed to wait for it to finish. However, code for recording the CUDA event was missing, so the other streams would find the default- constructed event, which is always "valid". Adding the missing call to record the event fixes the problem.
A new Pull Request was created by @fwyzard (Andrea Bocci) for CMSSW_11_3_X. It involves the following packages:
@makortel, @cmsbuild, @fwyzard can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
backport of #34725 |
type bugfix |
please test |
+heterogeneous |
This pull request is fully signed and it will be integrated in one of the next CMSSW_11_3_X IBs after it passes the integration tests and once validation in the development release cycle CMSSW_12_1_X is complete. This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy, @perrotta (and backports should be raised in the release meeting by the corresponding L2) |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6fb81f/17438/summary.html Comparison SummarySummary:
|
+1 |
PR description:
When multiple CUDA streams are trying to initialise the same EventSetup object, the first one to do so starts the asynchronous operations, and the others are supposed to wait for it to finish. However, code for recording the CUDA event was missing, so the other streams would find the default- constructed event, which is always "valid".
Adding the missing call to record the event fixes the problem.
PR validation:
See #34725 .
PR status:
Backport of #34725 to
CMSSW_11_3_X
.