doc: Add comment to cs_main and mempool::cs
This commit is contained in:
parent
fafe941bdd
commit
fa5c346c5a
2 changed files with 48 additions and 4 deletions
|
@ -485,7 +485,43 @@ public:
|
||||||
>
|
>
|
||||||
> indexed_transaction_set;
|
> indexed_transaction_set;
|
||||||
|
|
||||||
mutable CCriticalSection cs;
|
/**
|
||||||
|
* This mutex needs to be locked when accessing `mapTx` or other members
|
||||||
|
* that are guarded by it.
|
||||||
|
*
|
||||||
|
* @par Consistency guarantees
|
||||||
|
*
|
||||||
|
* By design, it is guaranteed that:
|
||||||
|
*
|
||||||
|
* 1. Locking both `cs_main` and `mempool.cs` will give a view of mempool
|
||||||
|
* that is consistent with current chain tip (`chainActive` and
|
||||||
|
* `pcoinsTip`) and is fully populated. Fully populated means that if the
|
||||||
|
* current active chain is missing transactions that were present in a
|
||||||
|
* previously active chain, all the missing transactions will have been
|
||||||
|
* re-added to the mempool and should be present if they meet size and
|
||||||
|
* consistency constraints.
|
||||||
|
*
|
||||||
|
* 2. Locking `mempool.cs` without `cs_main` will give a view of a mempool
|
||||||
|
* consistent with some chain that was active since `cs_main` was last
|
||||||
|
* locked, and that is fully populated as described above. It is ok for
|
||||||
|
* code that only needs to query or remove transactions from the mempool
|
||||||
|
* to lock just `mempool.cs` without `cs_main`.
|
||||||
|
*
|
||||||
|
* To provide these guarantees, it is necessary to lock both `cs_main` and
|
||||||
|
* `mempool.cs` whenever adding transactions to the mempool and whenever
|
||||||
|
* changing the chain tip. It's necessary to keep both mutexes locked until
|
||||||
|
* the mempool is consistent with the new chain tip and fully populated.
|
||||||
|
*
|
||||||
|
* @par Consistency bug
|
||||||
|
*
|
||||||
|
* The second guarantee above is not currently enforced, but
|
||||||
|
* https://github.com/bitcoin/bitcoin/pull/14193 will fix it. No known code
|
||||||
|
* in bitcoin currently depends on second guarantee, but it is important to
|
||||||
|
* fix for third party code that needs be able to frequently poll the
|
||||||
|
* mempool without locking `cs_main` and without encountering missing
|
||||||
|
* transactions during reorgs.
|
||||||
|
*/
|
||||||
|
mutable RecursiveMutex cs;
|
||||||
indexed_transaction_set mapTx GUARDED_BY(cs);
|
indexed_transaction_set mapTx GUARDED_BY(cs);
|
||||||
|
|
||||||
using txiter = indexed_transaction_set::nth_index<0>::type::const_iterator;
|
using txiter = indexed_transaction_set::nth_index<0>::type::const_iterator;
|
||||||
|
|
|
@ -210,9 +210,17 @@ private:
|
||||||
bool RollforwardBlock(const CBlockIndex* pindex, CCoinsViewCache& inputs, const CChainParams& params) EXCLUSIVE_LOCKS_REQUIRED(cs_main);
|
bool RollforwardBlock(const CBlockIndex* pindex, CCoinsViewCache& inputs, const CChainParams& params) EXCLUSIVE_LOCKS_REQUIRED(cs_main);
|
||||||
} g_chainstate;
|
} g_chainstate;
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Mutex to guard access to validation specific variables, such as reading
|
||||||
CCriticalSection cs_main;
|
* or changing the chainstate.
|
||||||
|
*
|
||||||
|
* This may also need to be locked when updating the transaction pool, e.g. on
|
||||||
|
* AcceptToMemoryPool. See CTxMemPool::cs comment for details.
|
||||||
|
*
|
||||||
|
* The transaction pool has a separate lock to allow reading from it and the
|
||||||
|
* chainstate at the same time.
|
||||||
|
*/
|
||||||
|
RecursiveMutex cs_main;
|
||||||
|
|
||||||
BlockMap& mapBlockIndex = g_chainstate.mapBlockIndex;
|
BlockMap& mapBlockIndex = g_chainstate.mapBlockIndex;
|
||||||
CChain& chainActive = g_chainstate.chainActive;
|
CChain& chainActive = g_chainstate.chainActive;
|
||||||
|
|
Loading…
Reference in a new issue