refactor: Make CAddrMan::cs non-recursive#19238
Conversation
|
cc @vasild :) |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
Concept ACK. I think the reason that |
|
oh wait you are not adding the annotations. Any reason for that? |
Added :) |
|
@MarcoFalke probably a1071f8 deserves its own PR as it blocks the similar changes in other parts of the code, right? |
vasild
left a comment
There was a problem hiding this comment.
Looks good, some suggestions below.
The last two commits:
Add means to handle negative capabilities in thread safety annotations
refactor: Add negative thread safety annotations to CAddrMan
are somewhat unrelated and maybe deserve a separate PR if they cause some controversy or if another reviewer asks to move them away to ease review. Since I already reviewed everything I am fine with them as they are.
d957293 to
1817751
Compare
1817751 to
b6712ec
Compare
|
Updated d957293 -> b6712ec (pr19238.02 -> pr19238.04):
|
…Thread Safety annotations f8213c0 Add means to handle negative capabilities in thread safety annotations (Hennadii Stepanov) Pull request description: This commit is separated from #19238, and it adds support of [Negative Capabilities](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#negative) in the Clang Thread Safety Analysis attributes. > Negative requirements are an alternative `EXCLUDES` [`LOCKS_EXCLUDED`] that provide a stronger safety guarantee. A negative requirement uses the `REQUIRES` [`EXCLUSIVE_LOCKS_REQUIRED`] attribute, in conjunction with the ! operator, to indicate that a capability should not be held. Examples of usage: - #19238 (for a class) - https://github.com/hebasto/bitcoin/tree/200610-addrman-tsn (for the whole code base) ACKs for top commit: MarcoFalke: Approach ACK f8213c0 vasild: ACK f8213c0 Tree-SHA512: 86d992826b87579661bd228712ae5ee6acca6f70b885ef7e96458974eac184e4874a525c669607ba6b6c861aa4806409a8792d100e6914c858bcab43d31cfb1b
b6712ec to
9cd0ed8
Compare
|
Updated b6712ec -> 9cd0ed8 (pr19238.04 -> pr19238.05):
|
|
The OP has been updated. |
|
@sipa Mind reviewing this PR? |
|
btw, how about convention to add the |
I like it, and it is shorter than |
ee79105 to
e2787fb
Compare
|
Rebased ee79105 -> e2787fb (pr19238.10 -> pr19238.11) due to the merging of #22025. |
e2787fb to
af95505
Compare
|
Rebased e2787fb -> af95505 (pr19238.11 -> pr19238.12) due to the conflict with #18722. |
|
Code review ACK af95505 |
|
There might be a silent merge conflict |
|
The unit test is single threaded, so there's no need to hold the mutex between Good() and Attempt(). This change avoids recursive locking in the CAddrMan::Attempt function. Co-authored-by: John Newbery <[email protected]>
With #21941. Rebasing. |
Change in the addrman.h header is move-only.
This change improves readability, and follows Developer Notes.
Co-authored-by: John Newbery <[email protected]>
Co-authored-by: John Newbery <[email protected]>
af95505 to
ae98aec
Compare
|
Rebased af95505 -> ae98aec (pr19238.12 -> pr19238.13) due to the silent merge conflict with #21941. |
This PR replaces
RecursiveMutex CAddrMan::cswithMutex CAddrMan::cs.All of the related code branches are covered by appropriate lock assertions to insure that the mutex locking policy has not been changed by accident.
Related to #19303.
Based on #22025, and first three commits belong to it.