Fix reorgBuffer race condition #724
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes a problem that led to random freezes because of the concurrent use of the reorgBuffer (aka scratchpad). So far, only the tick processor or the contract processor were allowed to use it (or the main processor if the tick and contract processors were not running). However, due to the use of the scratchpad in QPI::Collection and the use of Collection::add() -> Collection::_rebuild() in pendingTxsPool.add(), the reorgBuffer recently has also been used by the request processor without any locking. In consequence, concurrent execution of pendingTxsPool.add() and other functions using the reorgBuffer in the tick/contract processor led to undefined behaviour, usually freezing the request processor before leaving pendingTxsPool.add() and before unlocking pendingTxsPool.lock. As a clean solution, reorgBuffer has been replaced by commonBuffers, a class that supports concurrent use of multiple buffers with proper locking. In qubic.cpp, it is now configured to provide 2 buffers, in order to support concurrent execution of pendingTxsPool.add() and one other commonBuffers / scratchpad use case without blocking. When other use cases of commonBuffers / scratchpad will be added in the future, the console log output "Common buffers: [...] max waiting processors" should be monitored in order to decide about adding more buffers by changing COMMON_BUFFERS_COUNT.
Franziska-Mueller
approved these changes
Jan 26, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a problem that led to random freezes because of the concurrent use of the reorgBuffer (aka scratchpad). So far, only the tick processor or the contract processor were allowed to use it (or the main processor if the tick and contract processors were not running). However, due to the use of the scratchpad in QPI::Collection and the use of Collection::add() -> Collection::_rebuild() in pendingTxsPool.add(), the reorgBuffer recently has also been used by the request processor without any locking. In consequence, concurrent execution of pendingTxsPool.add() and other functions using the reorgBuffer in the tick/contract processor led to undefined behaviour, usually freezing the request processor before leaving pendingTxsPool.add() and before unlocking pendingTxsPool.lock.
As a clean solution, reorgBuffer has been replaced by commonBuffers, a class that supports concurrent use of multiple buffers with proper locking.
In qubic.cpp, it is now configured to provide 2 buffers, in order to support concurrent execution of pendingTxsPool.add() and one other commonBuffers / scratchpad use case without blocking.
When other use cases of commonBuffers / scratchpad will be added in the future, the console log output "Common buffers: [...] max waiting processors" should be monitored in order to decide about adding more buffers by changing COMMON_BUFFERS_COUNT.