Avoid race condition when conditionally starting Lumi begin stream#51280
Avoid race condition when conditionally starting Lumi begin stream#51280Dr15Jones wants to merge 4 commits into
Conversation
|
please test |
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51280/49888 |
|
A new Pull Request was created by @Dr15Jones for master. It involves the following packages:
@Dr15Jones, @makortel, @smuzaffar can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Problem was the atomic could be incremented after it was already decremented to 0 once. This lead to the endLumiAsync being called twice for the same Lumi.
|
please test |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51280/49890 |
|
Pull request #51280 was updated. @Dr15Jones, @makortel, @smuzaffar can you please check and sign again. |
|
Looks good to me |
|
+1 Size: This PR adds an extra 44KB to repository Comparison SummarySummary:
|
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51280/49926 |
|
Pull request #51280 was updated. @Dr15Jones, @makortel, @smuzaffar can you please check and sign again. |
|
+1 Size: This PR adds an extra 28KB to repository Comparison SummarySummary:
|
- guarantee that at least 1 stream processes a Lumi even if the Lumi has no Events
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51280/49939 |
|
Pull request #51280 was updated. @Dr15Jones, @cmsbuild, @makortel, @smuzaffar can you please check and sign again. |
|
please test |
The test holds an Event from the first Lumi until the Event from the 3rd Lumi is started. This forces the system to be able to skip the streamBeginLumi for the 2nd Lumi.
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-51280/49943
|
|
Pull request #51280 was updated. @Dr15Jones, @cmsbuild, @makortel, @smuzaffar can you please check and sign again. |
PR description:
Problem was the atomic could be incremented after it was already decremented to 0 once. This lead to the endLumiAsync being called twice for the same Lumi.
This fixes a problem seen in the IBs.
PR validation:
I had a small test program that tended to fail after 10s of 1000s of Lumis. With this changes, I have several times run a job which processed more than a million Lumis without issue.
resolves cms-sw/framework-team#2316
resolves #51265