[core] Moved post-hs-update locking code out of mutex; untangled lock order around RIDVector #1677
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
…r protection of RIDVector. Removed lock prevention on asynchro update.
maxsharabayko
added
[core]
Codecov Report
@@ Coverage Diff @@
## master #1677 +/- ##
==========================================
- Coverage 60.64% 60.36% -0.29%
==========================================
Files 78 78
Lines 17438 17442 +4
==========================================
- Hits 10575 10528 -47
- Misses 6863 6914 +51
Continue to review full report at Codecov.
|
maxsharabayko
approved these changes
Nov 30, 2020
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.
The problem:
There was detected a deadlock and therefore the
synchroparameter introduced, which passes down the call with a requirement to not lock the mutex, while it was causing a deadlock.After a deep mutex analysis it turned out that the deadlock was actually caused by a mutex lock ordering violation, which has started from the
CRendezvousQueue::updateConnStatus, which is called whole under a lock form_RIDVectorLock. The extra update calls introduced for HSv5 required extra locking, which was in lock ordering violation against this mutex. The problem has been solved by collecting all sockets, that need to be updated in this function by these lockable calls, in a separate container, and then call the updates outside of the lock.