A hashmap for lock entries in transaction's private memory.
Overview
This auxiliary data structure is to efficiently check what locks the transaction has already acquired. Because this is a transaction-private data structure and there is no multi-threads-per-transaction feature, we don't need any synchronization to access this. It uses no spinlock/mutex and is preferrable especially in multi-socket environment.
Multi-thread safety
get_granted_mode(), the method used from lock_m::lock(), has a precondition that says it must be called from the transaction's thread. The precondition is important because we don't take latch in get_granted_mode() nor return a copied lock mode (returns reference). As "this" is the only thread that might change granted mode of the lock entry or change the bucket's linked list, this is safe.
History
In original Shore-MT, there was only linked list. So, in order to check if a transaction already has some lock, we had to query the public lock table, entering critical sections. Further, Shore-MT had a feature to run a single transaction on multi-threads. There was no truly "private" memory back then for this reason. We found this causes an issue in NUMA environment, and made this private hashmap.
Performance Comparison
As of 20140213, with and without this improvement, TPCC on 4-socket machine is as follows: BEFORE=12027 TPS, AFTER=13764 TPS.
- Note
- yes, it's a copy-paste from XctLockHashMap, but this would be the only implementation.
