tip: 428
title: Increase the probability that the block processing thread acquires the lock
author:[email protected]
discussions to: https://github.com/tronprotocol/TIPs/issues/428
status: Final
type: Standards Track
category: Core
created: 2022-07-11
This TIP is to describe how to increase the probability that the block processing thread acquires the lock.
Online machines are generally 32 cores, and the probability of block threads competing for locks is 1/34. In high concurrency scenarios, if the average transaction execution time is 10ms, the average time for block threads to acquire locks is 340ms, which will lead to processing Block or production block delay, thereby reducing TPS and increasing the block loss rate.
Increase the probability of block thread acquiring locks, in order to improve TPS and reduce block loss rate.
- Transaction threads and block threads need to compete for the same lock, so reducing the number of transaction threads competing the lock at the same time can increase the probability of block threads acquiring locks.
- It is more efficient to use interruptible locks. When processing blocks, the transaction thread that owns the lock can be interrupted, so that the block thread can acquire the lock faster.
Synchronized is a blocking lock, there is no timeout mechanism, and it cannot be interrupted.
Lock supports non-blocking locking, supports timeout mechanism, and can acquire locks interruptible.
There are two options to increase the probability that the block thread acquires the lock.
One is to reduce the number of transaction threads competing the lock at the same time. If the number of transaction threads competing for locks at the same time is reduced to 1, the probability of the block thread acquiring the lock is 1/2.
The second is to use interruptible locks, which allows block threads to quickly acquire locks through the interrupt mechanism.
Comparison of the two schemes.
In the first solution, the code changes are relatively simple, and the lock cannot be interrupted, which is conducive to the development of other services in the future. But it needs to wait for the transaction thread that owns the lock to finish executing before the block thread can acquire the lock
The second scheme is more efficient to acquire the lock, but the implementation is more complicated, and it is necessary to add a lot of thread interrupt signal checking and processing in the process of transaction processing. And if other business threads need to acquire the lock later, other business threads may be interrupted, which makes business development very complicated.
After comprehensive consideration, the first solution is recommended.