-
Notifications
You must be signed in to change notification settings - Fork 37.8k
refactor: various RecursiveMutex replacements in CConnman #22829
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
refactor: various RecursiveMutex replacements in CConnman #22829
Conversation
829c50c
to
94a99d0
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code review ACK 94a99d0.
Concept ACK and clang 13 debug build is clean. |
why? What prevents |
The scripted diff could be shortened with a rename helper like 37dcd12 |
What concrete mutex are you referring to? Note that this PR only tackles the RecursiveMutex->Mutex replacement for
Good idea, will do in a bit. |
6ce979e
to
6f0930a
Compare
Force-pushed with changed commit subject for the scripted-diff (using a helper), as suggested by MarcoFalke (#22829 (comment)):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 6f0930a
Clang 12 build is clean with -Werror
.
mutable RecursiveMutex cs_totalBytesSent; | ||
uint64_t nTotalBytesRecv GUARDED_BY(cs_totalBytesRecv) {0}; | ||
std::atomic<uint64_t> nTotalBytesRecv{0}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: might use std::atomic_uint64_t
if it is available on all platforms that we aim to support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
std::atomic_uint64_t
The two are guaranteed to be the same either way.
LOCK2(m_addr_fetches_mutex, cs_vAddedNodes); | ||
if (m_addr_fetches.empty() && vAddedNodes.empty()) { | ||
LOCK2(m_addr_fetches_mutex, m_added_nodes_mutex); | ||
if (m_addr_fetches.empty() && m_added_nodes.empty()) { | ||
add_fixed_seeds_now = true; | ||
LogPrintf("Adding fixed seeds as -dnsseed=0, -addnode is not provided and all -seednode(s) attempted\n"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary for this PR, but it is a good practice to avoid printouts (which may block) while holding mutexes. Feel free to take this or ignore it:
- LOCK2(m_addr_fetches_mutex, m_added_nodes_mutex);
- if (m_addr_fetches.empty() && m_added_nodes.empty()) {
- add_fixed_seeds_now = true;
+ {
+ LOCK2(m_addr_fetches_mutex, m_added_nodes_mutex);
+ add_fixed_seeds_now = m_addr_fetches.empty() && m_added_nodes.empty();
+ }
+ if (add_fixed_seeds_now) {
LogPrintf("Adding fixed seeds as -dnsseed=0, -addnode is not provided and all -see
}
Concept ACK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 6f0930a, I have reviewed the code, and verified that there are no ways to lock the mentioned mutexes recursivly.
LOCK(m_added_nodes_mutex); | ||
m_added_nodes = connOptions.m_added_nodes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, could be
LOCK(m_added_nodes_mutex); | |
m_added_nodes = connOptions.m_added_nodes; | |
WITH_LOCK(m_added_nodes_mutex, m_added_nodes = connOptions.m_added_nodes); |
without surrounding braces.
Mayby, better to leave it (and other similar places) for a follow up.
…stead The RecursiveMutex cs_totalBytesRecv is only used at two places: in CConnman::RecordBytesRecv() to increment the nTotalBytesRecv member, and in CConnman::GetTotalBytesRecv() to read it. For this simple use-case, we can make the member std::atomic instead to achieve the same result.
-BEGIN VERIFY SCRIPT- ren() { sed -i "s/$1/$2/g" $3 $4 $5; } ren cs_vAddedNodes m_added_nodes_mutex src/net.h src/net.cpp ren vAddedNodes m_added_nodes src/net.h src/net.cpp ren cs_vNodes m_nodes_mutex src/net.h src/net.cpp src/test/util/net.h ren vNodesDisconnectedCopy nodes_disconnected_copy src/net.cpp ren vNodesDisconnected m_nodes_disconnected src/net.h src/net.cpp ren vNodesCopy nodes_copy src/net.cpp ren vNodesSize nodes_size src/net.cpp ren vNodes m_nodes src/net.h src/net.cpp src/test/util/net.h -END VERIFY SCRIPT-
The RecursiveMutex m_addr_fetches_mutex is used at three places: - CConnman::AddAddrFetch() - CConnman::ProcessAddrFetch() - CConnman::ThreadOpenConnections() In each of the critical sections, only the the m_addr_fetches is accessed (and in the last case, also vAddedNodes), without any chance that within one section another one is called. Hence, we can use an ordinary Mutex instead of RecursiveMutex.
The RecursiveMutex m_added_nodes_mutex is used at three places: - CConnman::GetAddedNodeInfo() - CConnman::AddNode() - CConnman::ThreadOpenConnections() In each of the critical sections, only the the m_added_nodes member is accessed (and in the last case, also m_addr_fetches), without any chance that within one section another one is called. Hence, we can use an ordinary Mutex instead of RecursiveMutex.
6f0930a
to
3726a45
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 3726a45
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code review ACK 3726a45.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-ACK 3726a45
This PR is related to #19303 and gets rid of the following RecursiveMutex members in class
CConnman
:cs_totalBytesRecv
, protectingnTotalBytesRecv
,std::atomic
is used instead (the member is only increment at one and read at another place, so this is sufficient)m_addr_fetches_mutex
, protectingm_addr_fetches
, a regularMutex
is used instead (there is no chance that within one critical section, another one is called)cs_vAddedNodes
, protectingvAddedNodes
, a regularMutex
is used instead (there is no chance that within one critical section, another one is called)Additionally, the PR takes the chance to rename all node vector members (vNodes, vAddedNodes) and its corresponding mutexes (cs_vNodes, cs_vAddedNodes) to match the coding guidelines via a scripted-diff.