[#CTxMemPool-cs]
= xref:CTxMemPool.adoc[CTxMemPool]::cs
:relfileprefix: ../
:mrdocs:

This mutex needs to be locked when accessing `mapTx` or other members that are guarded by it.

== Synopsis

Declared in `<txmempool.h>`

[source,cpp,subs="verbatim,replacements,macros,-callouts"]
----
[[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
xref:RecursiveMutex.adoc[RecursiveMutex] cs;
----

== 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 (`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.


[.small]#Created with https://www.mrdocs.com[MrDocs]#