简单的描述：
线程A 线程B
mutex1 enter mutex2 enter
mutex2 enter mutex1 enter
执行任务 执行任务
mutex2 release mutex1 release
mutex1 release mutex2 release
上面两个线程同时运行的时候，可能产生死锁的情况，就是A线程获得了mutex1正在等待mutex2的锁，同时线程2获得了mutex2正在等待mutex1的锁。在这种情况下，线程1在等线程2，线程2在等线程就造成了死锁。
了解了死锁的概念后，我们就可以开始分析innodb中关于死锁检测的流程细节，innodb的检车死锁的实质就是判断 要进行锁的latch是否会产生所有线程的闭环，这个是通过sync_array_cell_t的内容来判断的。在开始等待cell信号的时候， 会判断将自己的状态信息放入sync_array_cell_t当中，在进入os event wait之前会调用sync_array_detect_deadlock来判 断是否死锁，如果死锁，会触发一个异常。死锁检测的关键在与sync_array_detect_deadlock函数。 以下是检测死锁的流程描述：
1、将进入等待的latch对应的cell作为参数传入到sync_array_detect_deadlock当中，其中start的参数和依赖的cell参 数填写的都是这个cell自己。
2、进入sync_array_detect_deadlock先判断依赖的cell是否正在等待latch,如果没有，表示没有死锁，直接返回. 如果有，先判断等待的锁被哪个线程占用，并获得占用线程的id,通过占用线程的id和全局的sync_array_t 等待cell数组状 态信息调用sync_array_deadlock_step来判断等待线程的锁依赖。 3、进入sync_array_deadlock_step先找到占用线程的对应cell,如果cell和最初的需要event wait的cell是同一 个cell,表示是一个闭环，将产生死锁。如果没有，继续将查询到的cell作为参数递归调用 sync_array_detect_deadlock执行第2步。这是个两函数交叉递归判断的过程。 在检测死锁过程latch句柄、thread id、cell句柄三者之间环环相扣和递归，通过latch的本身的状态来判断闭环死锁。在上面的第2步会根据latch是mutex和rw_lock的区别做区分判断，这是由于mutex和rw_lock的运作机制不同造成的。因为关系
数据库的latch使用非常频繁和复杂，检查死锁对于锁的调试是非常有效的，尤其是配合thread_levels状态信息输出来做调试，对死锁排查是非常有意义的。
死锁示意图:
6.总结 通过上面的分析可以知道innodb除了实现对操作
系统提供的latch结构封装意外，还提供了原子操作级别的自定义latch，那么它为什么要实现自定义latch呢 我个人理解主要是减少操作系统上下文的切换，提高并发的效率。innodb中实现的自定义latch只适合短时间的锁等待（最好不超过50us）,如果是长时间锁等待，最好还是使用操作系统提供的，虽然自定义锁在等待一个自旋周期会进入操作系统的event_wait，但这无疑比系统的mutex lock耗费的资源多。最后我们还是看作者在代码中的总结： We conclude that the best choice is to set the spin time at 20 us. Then the system should work well on a multiprocessor. On a uniprocessor we have to make sure that thread swithches due to mutex collisions are not frequent, i.e., they do not happen every 100 us or so, because that wastes too much resources. If the thread switches are not frequent, the 20 us wasted in spin loop is not too much.
|