feat(txpool): calculate consumption when committing a new block #1554
Conversation
- put store reader before message channel - add comment private for ConsumptionBlocks - move ConsumptionBlocks to down of struct config - move handle committed block after write batch
|
|
||
| p.consumptionMap[signer] += uint32(trx.SerializeSize()) | ||
| } |
There was a problem hiding this comment.
I think it's better to have atomic increase to prevent race conditions on consumptionMap
There was a problem hiding this comment.
For the consumptionMap map[crypto.Address]uint32, atomic operations are typically not necessary unless multiple goroutines concurrently read and modify the same uint32 values in the map. A map in Go is not thread-safe, so accessing or modifying it concurrently requires synchronization (e.g., using sync.Mutex).
However, if the map is safely guarded by a lock or accessed in a single-threaded context, atomic operations for the values aren't required.
There was a problem hiding this comment.
I mean, we can't guarantee scope of use of consumptionMap in long term.
Although we can guarantee that handleIncreaseConsumption is locked but it is likely that another function or goroutine accesses consumptionMap in different scope using different lock, which is not safe.
There was a problem hiding this comment.
handleIncreaseConsumption and handleDecreaseConsumption have parent lock from HandleCommittedBlock.
In HandleCommittedBlock we don't have concurrent for increase and decrease.
Description
Calculate consumption when committing a new block
Related issue(s)