Avoid locking CTxMemPool::cs recursively in CTxMemPool::DynamicMemoryUsage()#19901
Avoid locking CTxMemPool::cs recursively in CTxMemPool::DynamicMemoryUsage()#19901hebasto wants to merge 3 commits intobitcoin:masterfrom
Conversation
No change in behavior, some call sites already held the lock and a lock is added in the remaining sites.
|
Looks like this is adding a lot of code (complexity). Not sure if that is worth it. |
Since the memory unused by the mempool could be used by the coinscache, |
http://www.erisian.com.au/bitcoin-core-dev/log-2020-06-18.html#l-16:
|
|
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. |
|
🐙 This pull request conflicts with the target branch and needs rebase. Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft". |
3 participants
This is another step to transit
CTxMemPool::csfromRecursiveMutextoMutex.Split out from #19306. (Along with #19652, #19854 and #19872 it is more than 2/3 of the way to the final goal).
Thread safety annotations, lock assertions, and required explicit locking added. No behavior change.
Please note that now, since #19668 has been merged, it is safe to apply
AssertLockHeld()macros as they do not swallow compile time Thread Safety Analysis warnings.