[#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&period;

== Synopsis

Declared in `&lt;txmempool&period;h&gt;`

[source,cpp,subs="verbatim,replacements,macros,-callouts"]
----
&lsqb;&lsqb;acquired&lowbar;after(0x7f2e1b5a1358), acquired&lowbar;after(0x7f2e2721a368), acquired&lowbar;after(0x7f2e421cba78), acquired&lowbar;after(0x7f2e2880aa38), acquired&lowbar;after(0x7f2e3212ddc8), acquired&lowbar;after(0x7f2e347f6458), acquired&lowbar;after(0x7f2e2b05a8c8), acquired&lowbar;after(0x7f2e2bee1f68)&rsqb;&rsqb;
mutable
xref:RecursiveMutex.adoc[RecursiveMutex] cs;
----

== Consistency guarantees

By design, it is guaranteed that&colon; 1&period; Locking both `cs&lowbar;main` and `mempool&period;cs` will give a view of mempool that is consistent with current chain tip (`ActiveChain()` and `CoinsTip()`) and is fully populated&period; 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&hyphen;added to the mempool and should be present if they meet size and consistency constraints&period; 2&period; Locking `mempool&period;cs` without `cs&lowbar;main` will give a view of a mempool consistent with some chain that was active since `cs&lowbar;main` was last locked, and that is fully populated as described above&period; It is ok for code that only needs to query or remove transactions from the mempool to lock just `mempool&period;cs` without `cs&lowbar;main`&period;

To provide these guarantees, it is necessary to lock both `cs&lowbar;main` and `mempool&period;cs` whenever adding transactions to the mempool and whenever changing the chain tip&period; It&apos;s necessary to keep both mutexes locked until the mempool is consistent with the new chain tip and fully populated&period;


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