This mutex needs to be locked when accessing mapTx or other members that are guarded by it.
Declared in <txmempool.h>
[[acquired_after(0x7f2e1b5a1358), acquired_after(0x7f2e2721a368), acquired_after(0x7f2e421cba78), acquired_after(0x7f2e2880aa38), acquired_after(0x7f2e3212ddc8), acquired_after(0x7f2e347f6458), acquired_after(0x7f2e2b05a8c8), acquired_after(0x7f2e2bee1f68)]]
mutable
RecursiveMutex cs;
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 (ActiveChain() and CoinsTip()) 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.