Innodb行锁（1）：加锁流程

三、总结

这里我们看到如下：

下一篇我们来分析一下lock monitor线程的超时唤醒方式，然后再来看lock monitor线程的死锁检测方式。

四、代码流程

lock_rec_lock_slow
   locksys::owns_page_shard(block->get_page_id())
   注意这个锁，对lock_sys mutex的优化
  ->lock_rec_has_expl(checked_mode, block, heap_no, trx); 
    该session 是否已经包含了 本模式的或者更强模式的锁
    如果是则不需要锁判断了
  ->lock_rec_other_has_conflicting，本函数返回是否有需要等待的锁
    进行锁冲突判定,如果返回找到的锁wait_for，就是拥有更强锁
    ->RecID rec_id{block, heap_no}
      通过block和heapno构建rec id
    ->is_supremum = rec_id.is_supremum()
      是否为sup伪列
    ->Lock_iter::for_each(rec_id, [=](const lock_t *lock) {return (!(lock_rec_has_to_wait(trx, mode, lock, is_supremum))
      使用迭代，带入的为lambda函数，内部也就是循环比对
      ->hash_get_nth_cell(hash_table,hash_calc_hash(rec_id.m_fold, hash_table))
        首先根据rec信息进行hash查找，在lock_sys的hash结构中进行查找，找到相应的链表
        也就是lock_sys->rec_hash
      ->for (auto lock = first(list, rec_id); lock != nullptr; lock = advance(rec_id, lock))
        遍历链表信息,每个信息是一个lock_rec_t结构
        ->!std::forward<F>(f)(lock) 完美转发，右值引用
          回调 lambda函数，进去= 值捕获
          ->lock_rec_has_to_wait
            ->is_hp = trx_is_high_priority(trx)
              sql线程拥有更高的优先级
            ->lock_mode_compatible
              进行锁强度判定，特殊情况为如果线程优先级更高则忽略
              及lock_compatibility_matrix兼容性矩阵
            ->进行额外的判定
            如果返回为true则表明有其他事务的锁需要等待，如果为false
            则不需要等待
    如果需要等待，则 return (lock)，返回等待的lock   
  ->(wait_for != nullptr)
     如果等待的锁不为空，这里注意几个属性SKIP LOCKED / NOWAIT是语句设置的时候的属性
     这里会进行锁的判定，这里跳过SELECT_SKIP_LOCKED/SELECT_NOWAIT
  ->SELECT_ORDINARY
    ->RecLock rec_lock(thr, index, block, heap_no, mode)
      新建一个RecLock结构，lock rec的内存结构，调用的为其构造函数
       m_thr(thr),m_trx(thr_get_trx(thr)),m_mode(mode),m_index(index),m_rec_id(rec_id)       
    ->trx_mutex_enter(trx)
      上事务结构锁
      Mutex protecting the fields `state` and `lock`
    ->rec_lock.add_to_waitq(wait_for) RecLock::add_to_waitq
      输入参数为需要等待的lock_t结构
      ->m_mode |= LOCK_WAIT
        首先将锁设置为LOCK_WAIT
      ->prepare()
        RecLock::prepare
        做简单检查先不考虑
      ->lock_t *lock = create(m_trx, prdt)
        进行创建lock_t结构,调用RecLock::create
        ->lock_alloc(trx, m_index, m_mode, m_rec_id, m_size)
          RecLock::lock_alloc，这里可以看到输入的信息都是
          已经通过前面获取的信息比如锁模型，当前事务结构，space/page no/heap no等等
          ->(trx->lock.rec_cached >= trx->lock.rec_pool.size() ||sizeof(*lock) + size > REC_LOCK_SIZE)
            如果((gdb) p trx->lock.rec_pool.size() $2 = 8)加锁的lock_t结构数量大于了8个就需要分配内存了
            否则直接从pool里面拿，系统预先分配了REC_LOCK_CACHE的lock_t结构内存，就是8个。
          ->lock->trx = trx/lock->index = index/lock->type_mode = LOCK_REC | (mode & ~LOCK_TYPE_MASK)
            /memset(&lock[1], 0x0, size)/ rec_lock.page_id = rec_id.get_page_id()
            /lock_rec_set_nth_bit(lock, rec_id.m_heap_no)
            设置相关信息，将锁的信息进行记录，并且lock->trx->lock.n_rec_locks.fetch_add +1
          最后返回这个lock_t结构相关的变量
        ->RecLock::lock_add
          将这个lock_t结构放入到hash结构中
          ->bool wait = m_mode & LOCK_WAIT;
            是否处于等待状态               
          ->lock->index->table->n_rec_locks.fetch_add(1, std::memory_order_relaxed);
            增加锁定的行数 +1
          ->if (!wait)
            是否处于等待状态，如果不是
            lock_rec_insert_to_granted(lock_hash, lock, m_rec_id)
             ->首先获取cell，使用头插法插入到链表的头部
            否则
            lock_rec_insert_to_waiting(lock_hash, lock, m_rec_id)      
             ->直接插入到响应cell的尾部       
          ->locksys::add_to_trx_locks(lock)
            ->UT_LIST_ADD_LAST(lock->trx->lock.trx_locks, lock)
              将锁结构加入到事务的trx_lock_t中
            ->lock->trx->lock.trx_locks_version++
              locks版本+1
          ->if (wait)
            ->lock_set_lock_and_trx_wait
             ->trx->lock.wait_lock = lock; //写入
             ->trx->lock.wait_lock_type = lock_get_type_low(lock);
               如果是处于等待状态，则将这个锁放入到事务的trx_lock_t->wait_lock中          
      ->lock_create_wait_for_edge     
        输入参数为当前事务的trx(waiter)和等待的trx(被堵塞blocker)
        waiter->lock.blocking_trx.store(blocker)
        记录当前等待的事务的堵塞源头事务,存储一条边，记录了堵塞者
      ->RecLock::set_wait_state
        m_trx->lock.wait_started = ut_time();
        m_trx->lock.que_state = TRX_QUE_LOCK_WAIT;
        m_trx->lock.was_chosen_as_deadlock_victim = false;
        以上设置事务lock的状态，show engine中事务的状态就是它
            case TRX_QUE_LOCK_WAIT:fputs("LOCK WAIT ", f);break;
        并且innodb_trx中的状态也会根据其进行判定，fill_trx_row->trx_get_que_state_str
        也是一样的状态
        同时innodb_trx中的trx_wait_started也是来自这里，如果等待了就设置为时间，没有等待则为NULL
        
         stopped = que_thr_stop(m_thr)
         用于返回用于加锁等待的 判定QUE_THR_LOCK_WAIT
      ->thd_report_row_lock_wait
        使用当前线程和需要等待的线程，如果是SQL线程则需要根据seqnumber进行死锁判定
        if (self != nullptr && wait_for != nullptr && is_mts_worker(self) &&is_mts_worker(wait_for))
        ->Commit_order_manager::check_and_report_deadlock(self, wait_for);
           if (mngr != nullptr && self_w->c_rli == wait_for_w->c_rli &&wait_for_w->sequence_number() > self_w->sequence_number())
           这里根据sequence_number进行判定
           ->Commit_order_manager::report_deadlock
             在研究
      ->return (DB_LOCK_WAIT)
       返回状态DB_LOCK_WAIT
    ->trx_mutex_exit(trx);
      进行解锁，也就是上面的过程是在trx_t的mutex下进行的
    ->返回堵塞状态DB_LOCK_WAIT
    以上是堵塞的流程
    ->如果没有堵塞则
    ->lock_rec_add_to_queue
     -> type_mode |= LOCK_REC;
     -> if (!(type_mode & LOCK_WAIT))
        如果不处于等待状态，因为lock_rec_add_to_queue函数并不是只有
        这里才会调用，调用的地方还很多，这里看起来不会处于LOCK_WAIT
        状态
        ->lock_hash_get(type_mode)/lock_rec_get_first_on_page(hash, block)
          通过lock_system hash结构找到相关的第一个lock_t结构
        ->lock_rec_find_similar_on_page
          主要是通过对hash的链表进行for循环，看本事务是否已经有合适的lock_t结构了，如果有则只需要设置响应的bit位就可以了。主要比对的方式
          1、事务是同一个
          2、锁模式相同
          3、并且此lock_t的bit结构能够容纳下
          ->lock_rec_set_nth_bit(lock, heap_no)
            如果找到就进行bit位设置
        ->否则就需要新建新建lock_t结构，并且调用的也是RecLock::create
          并且加锁trx_mutex_enter(trx)，当然也包含了加入到lock_system
          hash结构中,流程如上，不在详细描述。