-
Notifications
You must be signed in to change notification settings - Fork 2
[FreshEyes] locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip #17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: bitcoin-fresheyes-staging-master-30111
Are you sure you want to change the base?
Conversation
We need to synchronize between various tx download structures. TxRequest does not inherently need cs_main for synchronization, and it's not appropriate to lock all of the tx download logic under cs_main.
This is a synchronous version of UpdatedBlockTip. It allows clients to respond to a new block immediately after it is connected. The synchronicity is important for things like m_recent_rejects, in which a transaction's validity can change (rejected vs accepted) when this event is processed (e.g. it has a timelock condition that has just been met). This is distinct from something like m_recent_confirmed_transactions in which the validation outcome is the same (valid vs already-have).
Resetting m_recent_rejects once per block is more efficient than comparing hashRecentRejectsChainTip with the chain tip every time we call AlreadyHaveTx. We keep hashRecentRejectsChainTip for now to assert that updates happen correctly; it is removed in the next commit.
This also means AlreadyHaveTx no longer needs cs_main held.
The lock doesn't exist anymore. -BEGIN VERIFY SCRIPT- sed -i 's/EraseTxNoLock/EraseTxInternal/g' src/txorphanage.* -END VERIFY SCRIPT-))'
|
There were 14 comments left by 3 reviewers, 1 bot and the author for this pull request |
| LOCK(m_recent_confirmed_transactions_mutex); | ||
| if (m_recent_confirmed_transactions.contains(hash)) return true; | ||
| } | ||
| if (m_recent_confirmed_transactions.contains(hash)) return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 authors commented here with:
- comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601841903at 2024/05/15, 15:19:53 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601878592at 2024/05/15, 15:43:26 UTC.
|
|
||
| /** Storage for orphan information */ | ||
| TxOrphanage m_orphanage; | ||
| TxOrphanage m_orphanage GUARDED_BY(m_tx_download_mutex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4 authors commented here with:
- comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601902513at 2024/05/15, 15:59:50 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1602816185at 2024/05/16, 08:07:47 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1602847832at 2024/05/16, 08:23:19 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1603602970at 2024/05/16, 15:29:17 UTC.
| } | ||
| } // release MempoolMutex | ||
| if (notify_updated_tip) { | ||
| m_chainman.m_options.signals->UpdatedBlockTipSync(pindexNewTip); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4 authors commented here with:
- comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601903709at 2024/05/15, 16:00:46 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601920676at 2024/05/15, 16:13:15 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601923988at 2024/05/15, 16:15:58 UTC - comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601946313at 2024/05/15, 16:33:58 UTC.
| fInitialDownload); | ||
| } | ||
|
|
||
| void ValidationSignals::UpdatedBlockTipSync(const CBlockIndex *pindexNew) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An author commented here with:
- comment link
https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1601944049at 2024/05/15, 16:32:08 UTC.
The author glozow wrote the following PR called locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip, issue number 30111 in bitcoin/bitcoin cloned by FreshEyes below:
See
#27463for full project tracking.This contains the first 4 commits of
#30110, which require some thinking about thread safety in review.m_tx_download_mutexwhich guards the transaction download data structures includingm_txrequest, the rolling bloom filters, andm_orphanage. Later this should become the mutex guardingTxDownloadManager.m_txrequestdoesn't need to be guarded usingcs_mainanymorem_recent_confirmed_transactionsdoesn't need its own lock anymorem_orphanagedoesn't need its own lock anymoreValidationInterfaceevent,UpdatedBlockTipSync, which is a synchronous version ofm_txrequest0.m_txrequest1 andm_txrequest2 onm_txrequest3 just once instead of every timem_txrequest4 is called. This should speed up calls to that function and removes the need to lockm_txrequest5 every time it is called.