Skip to content

Conversation

theStack
Copy link
Contributor

This PR is related to #19303 and gets rid of the RecursiveMutex cs_SubVer. Both of the critical sections only directly access the guarded variable, i.e. it is not possible that within one section another one is called, and we can use a regular Mutex.

@theStack theStack changed the title refactor: replace RecursiveMutex cs SubVer with Mutex (and rename) refactor: replace RecursiveMutex cs_SubVer with Mutex (and rename) Jan 16, 2022
@hebasto
Copy link
Member

hebasto commented Jan 16, 2022

This mutex was added in 22b4966 back in 2017.

Maybe it is out of this PR scope, but in the current codebase I see no reasons for it because a write operation is executed once only during processing the received VERSION message.

-BEGIN VERIFY SCRIPT-
sed -i 's/cs_SubVer/m_subver_mutex/g' ./src/net.h ./src/net.cpp ./src/net_processing.cpp
-END VERIFY SCRIPT-
In each of the critical sections, only the the guarded variable is
accessed, without any chance that within one section another one is
called.  Hence, we can use an ordinary Mutex instead of RecursiveMutex.
@theStack theStack force-pushed the 202201-refactor_replace_RecursiveMutex_cs_subver branch from 2b92572 to 30927cb Compare January 16, 2022 15:52
@theStack
Copy link
Contributor Author

theStack commented Jan 16, 2022

Maybe it is out of this PR scope, but in the current codebase I see no reasons for it because a write operation is executed once only during processing the received VERSION message.

I agree that it's unlikely, but isn't there still a non-zero probability that access could happen concurrently? Processing of a VERSION message could in theory happen during a getpeerinfo RPC call -- a peer is already in the nodes list before the version exchange is completed.

Copy link
Member

@hebasto hebasto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 30927cb, I have reviewed the code and it looks OK, I agree it can be merged.

@maflcko maflcko merged commit dbf81a7 into bitcoin:master Jan 17, 2022
@theStack theStack deleted the 202201-refactor_replace_RecursiveMutex_cs_subver branch January 17, 2022 11:33
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jan 18, 2022
…h Mutex (and rename)

30927cb refactor: replace RecursiveMutex `m_subver_mutex` with Mutex (Sebastian Falbesoner)
0639aba scripted-diff: rename `cs_SubVer` -> `m_subver_mutex` (Sebastian Falbesoner)

Pull request description:

  This PR is related to bitcoin#19303 and gets rid of the RecursiveMutex `cs_SubVer`. Both of the critical sections only directly access the guarded variable, i.e. it is not possible that within one section another one is called, and we can use a regular Mutex.

ACKs for top commit:
  hebasto:
    ACK 30927cb, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: 2faead792ea0b2f79f9f7fe99acde5cf2bfcd2f15c51fbb6cb1099d4f81276001a492f7d46a5139055f4366c2d58a36a8ba19f21d56df20e0ed93af3141dbe11
@bitcoin bitcoin locked and limited conversation to collaborators Jan 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants