MySQL8.0 - InnoDB里的Latch定义-白红宇

最近在看InnoDB关于mutex定义部分的代码，由于之前一直工作在MySQL5.6版本里，发现从5.7开始到8.0，这部分代码已经完全进行了重构，本文主要简单记录下新款latch的定义和使用方式。主要记录下涉及的函数和类，不做具体的深入

首先mutex的定义分为三个部分:

PolicyMutex：定义了mutex的接口，包括

enter();exit();try_lock();init();...

PolicyMutex私有成员m_impl，通过模板实例化为具体的实现方式:

TTASFutexMutex
    
        FutexMutexTTASFutexMutex
     
        BlockFutexMutexTTASMutex
      
           SpinMutexTTASMutex
       
          BlockSpinMutexOSTrackMutex
        
           SysMutexOSTrackMutex
         
           BlockSysMutexTTASEventMutex
          
            SyncArrayMutexTTASEventMutex
           
             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类做进一步的判断