[DAQ] fix unsafe vector handling in input sources (13_1_X) #41669
Conversation
condition-variable thread that is part of a vector being expanded. - remove synchronization point since creation of a thread already implies a memory barrier.
- intialize vectors before spawning threads to avoid waiting on a condition-variable thread that is part of a vector being expanded. - remove synchronization point since creation of a thread already implies a memory barrier.
|
A new Pull Request was created by @smorovic (Srecko Morovic) for CMSSW_13_1_X. It involves the following packages:
@cmsbuild, @emeschi, @smorovic can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
smorovic
changed the title
|
backport of #41668 |
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ebeffa/32617/summary.html Comparison SummarySummary:
|
|
+1 |
cmsbuild
added
daq-approved
fully-signed
and removed
daq-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_13_1_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_13_2_X is complete. This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
|
+1
|
PR description:
Rare, spurious crashes have been obsever in input source initialization in HLT. Analysis points to a possibility of a vector being reallocated to a different heap location while threads wait on a condition variable.
(Not an urgent issue, since it causes minimal impact online and no data loss).
Solution is to initialize vectors before spawning threads using them.
Also, an opportunity was taken to wrap CV variables within a unique pointer instead of having to delete them in destructor and to remove a memory synchronization point, since creation of a thread already is one.
PR validation:
Tested with 13_0_6 in a DAQ test cluster for production FedRawDataInputSource . Also covered by unit tests for both sources.
If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
Backport of #41668