最近在看InnoDB关于mutex定义部分的代码，由于之前一直工作在MySQL5.6版本里，发现从5.7开始到8.0，这部分代码已经完全进行了重构，本文主要简单记录下新款latch的定义和使用方式。主要记录下涉及的函数和类，不做具体的深入
首先mutex的定义分为三个部分:
PolicyMutex：定义了mutex的接口，包括
enter();
exit();
try_lock();
init();
...PolicyMutex私有成员m_impl，通过模板实例化为具体的实现方式:
TTASFutexMutex<GenericPolicy> FutexMutex
TTASFutexMutex<BlockMutexPolicy> BlockFutexMutex
TTASMutex<GenericPolicy> SpinMutex
TTASMutex<BlockMutexPolicy> BlockSpinMutex
OSTrackMutex<GenericPolicy> SysMutex
OSTrackMutex<BlockMutexPolicy> BlockSysMutex
TTASEventMutex<GenericPolicy> SyncArrayMutex
TTASEventMutex<BlockMutexPolicy> BlockSyncArrayMutex可以看到，这里定义了4种Mutex，两种policy，前者是Mutex的具体实现，后者用于跟踪mutex的counter信息
4种mutex包括:
TTASFutexMutex:
- enter: 首先spin通过cas检查锁状态，如果无法通过原子操作获得锁，则调用wait()使用futex进入等待：
syscall(SYS_futex, &m_lock_word, FUTEX_WAIT_PRIVATE, MUTEX_STATE_WAITERS,
0, 0, 0);
//原子检查m_Lock_word是否为MUTEX_STATE_WAITERS, 如果是，则休眠- exit:释放锁后，如果有等待的线程，同样通过syscall去唤醒
syscall(SYS_futex, &m_lock_word, FUTEX_WAKE_PRIVATE, 1, 0, 0, 0);futex运行于用户态， 是fast usetablespace mutex的缩写, 对于冲突较小的互斥锁，运行于用户态可以减少内核层切换的开销，futex说明文档
TTASMutex:
- 纯粹的spin loop循环，直到成功加锁(即成功通过原子操作修改lock_word为locked状态)
- 适用于竞争很少的场景
TTASEventMutex
- 传统的Innodb实现方式
- 先spin一段时间，如果一直枷锁失败，则进入condition wait，等待被唤醒
OSTrackMutex:
- 就是封装了pthread_mutex
- 适用于冲突比较剧烈的锁场景
两种Policy
- GenericPolicy：适用于只有一个对应的mutex，也就是一个Latch id只对应一个锁对象
- BlockMutexPolicy：用于追踪block mutex，由于涉及到大量的block mutex，对这类锁的counter跟踪需要进行聚合
- 每个latch有一个policy，每个policy维持一个counter(LatchCounter), 记录了latch spin_loop, spin_wait及调用的次数
- Policy的成员m_counter会被注册到latch_meta::m_counter中
LatchMeta:
- 为了管理和聚合counter信息，每类Latch对应一个Id, 通过id找到对应的
latch_meta_t, 其中LatchMeta维护了锁的id, latch level等信息; - 存储在数组LatchMetaData中，下标为latch id
CreateTracker:
- 所有的Latch对象被注册到这个类中
我们知道，在debug模式下，innodb还实现了一套机制，也就是通过sync level, 来判断是否违背了加锁顺序，如果有的话，在debug模式下会assert，提示有潜在的deadlock风险
这里涉及到三个类:
- MutexDebug: 通过Policy类调用其成员函数
- 在进入一个latch时, 生成一个context(MutexDebug的私有类)存储当前的所信息
- context被传到函数sync_check_lock_validate中，通过
LatchDebug类做进一步的判断
