Fix a potencial race in CWallet::ListCoins.
Replaces cs_main and cs_wallet locks by assertions in CWallet::AvailableCoins.
Fix a potencial race in CWallet::ListCoins.
Replaces cs_main and cs_wallet locks by assertions in CWallet::AvailableCoins.
Note to reviewers, 2nd commit is just indentation, see 1st commit. I'll squash before merge.
Just noting that you can fixup right now. It is possible to ignore-all-space in git diff
I know but IIRC it's not possible to add comments with that option, so I've decided to split for now.
2197 | @@ -2198,111 +2198,109 @@ CAmount CWallet::GetAvailableBalance(const CCoinControl* coinControl) const 2198 | 2199 | void CWallet::AvailableCoins(std::vector<COutput> &vCoins, bool fOnlySafe, const CCoinControl *coinControl, const CAmount &nMinimumAmount, const CAmount &nMaximumAmount, const CAmount &nMinimumSumAmount, const uint64_t nMaximumCount, const int nMinDepth, const int nMaxDepth) const 2200 | { 2201 | + AssertLockHeld(cs_main); 2202 | + AssertLockHeld(cs_wallet);
Both are recursive locks, so any reason we can't just use LOCK2 here?
Long term plan is to remove recursive locks. Correct me if I'm wrong @TheBlueMatt.
I think in general we want to move away from recursive locking: https://github.com/bitcoin/bitcoin/blob/85123be78df5a4e9447e70f9ee727416d45843d7/src/sync.h#L92
http://www.zaval.org/resources/library/butenhof1.html has some interesting rationale and history
Thanks @ryanofsky for the reference.
Ah, thanks for the clarification.
Yes, recursive locking is one of the codebase's sins that we inherited and should be corrected in the long run.
utACK 834529f3c097386b82feb01bd2cc3e0f90418813. To make the locking change easier to evaluate, I might give the second commit (834529f3c097386b82feb01bd2cc3e0f90418813) a description indicating it is an indentation-only change, instead of squashing it.
utACK 834529f3c097386b82feb01bd2cc3e0f90418813 (very easy to review with -w / ?w=1).
Followed @ryanofsky suggestion, 1st commit and 2nd commit.
utACK 4848f093c4755794ca57c6514cb1e3c484cf3867, only change since last review is commit description
676 | @@ -677,11 +677,11 @@ BOOST_FIXTURE_TEST_CASE(ListCoins, ListCoinsTestingSetup) 677 | 678 | // Lock both coins. Confirm number of available coins drops to 0. 679 | std::vector<COutput> available; 680 | + LOCK2(cs_main, wallet->cs_wallet);
This locks the cs_main and cs_wallet for the entire rest of this test, which is somewhat awkward scoping-wise, is that intentional?
Nothing else happens and below the lock is again required so I've decided for the minimal diff. I can lock only until ListCoins below if you prefer.
Yes please, For readability I prefer locks to be taken at the beginning of a block.
Done, 2 blocks instead of one.