tapyrus-core
tapyrus-core copied to clipboard
chaintope
Improve shared data locking and Synchronisation
In the bitcoin-core codebase, many improvements have been made to keep shared data protected by critical section.
These classes are some examples:
-
NetEventsInterface -
CNodeState -
CConnman -
CMainSignals -
CBlockPolicyEstimator -
CWallet -
CCheckQueue
GUARDED_BY, EXCLUSIVE_LOCKS_REQUIRED and SHARED_LOCKS_REQUIRED definitions are available in Tapyrus. These can be used to make data thread safe
CCheckQueue and CMainSignals were updated as part of boost::thread to std::thread migration.
CWallet and CBlockPolicyEstimator classes in Bitcoin are very different from our classes. So adding GUARDED_BY and EXCLUSIVE_LOCKS_REQUIRED caused deadlock.
CNodeState and CConnman classes are further divided in bitcoin and new mutexex added to protect the new data. Our classes are sufficiently protected. So these do not need changes.
NetEventsInterface and CAddrMan classes have exactly the same mutex as bitcoin. but adding more locks to match bitcoin code caused deadlock in functional tests. SO these are not changed.
Our old class names are changed to Mutex and RecursiveMutex like bitcoin. RecursiveMutex may be locked more than once by the same thread without blocking. Mutex is always blocking.
Most of our mutexes like cs_main, cs_wallet, mempool.cs are recursive. Many are global. These are locked at the beginning of a message processing and not just at the places where shared data is accessed or modified. It would require a huge effort to redesign these and make them non recursive. Performance benefit would be significant. But development and testing effort need to be planned before attempting it.
