innodb是一个多线程并发的存储引擎，内部的读写都是用多线程来实现的，所以innodb内部实现了一个比較高效的并发同步机制。
innodb并没有直接使用系统提供的锁(latch)同步结构，而是对其进行自己的封装和实现优化。可是也兼容系统的锁。我们先看一段innodb内部的凝视（MySQL-3.23）:
Semaphore operations in operating systems are slow: Solaris on a 1993 Sparc takes 3 microseconds (us) for a lock-unlock pair and Windows NT on a 1995 Pentium takes 20 microseconds for a lock-unlock pair. Therefore, we have toimplement our own efficient spin lock mutex. Future operating systems mayprovide efficient spin locks, but we cannot count on that.
大概意思是说1995年的时候。一个Windows NT的 lock-unlock所须要耗费20us,即使是在Solaris 下也须要3us,这也就是他为什么要实现自己定义latch的目的,在innodb中作者实现了系统latch的封装、自己定义mutex和自己定义rw_lock。以下我们来一一做分析。
1 系统的mutex和event
在innodb引擎其中，封装了操作系统提供的基本mutex（相互排斥量）和event（信号量）。在WINDOWS下的实现临时不做记录，主要还是对支持POSIX系统来做介绍。在POSIX系统的实现是os_fast_mutex_t和os_event_t。os_fast_mutex_t相对简单，事实上就是pthread_mutex。
定义例如以下：
typedef pthread_mutex os_fast_mutex_t;typedef struct os_event_struct
{
os_fast_mutex_t os_mutex;
ibool is_set;
pthread_cond_t cond_var;
}os_event_t;
对于系统的封装，最基本的就是os_event_t接口的封装。而在os_event_t的封装中，os_event_set、os_event_reset、os_event_wait这三
个方法是最关键的。
2 CPU原子操作
在innodb的mutex(相互排斥量)的实现中，除了引用系统的os_mutex_t以外，还使用了原子操作来进行封装一个高效的mutex实现。
在
系统支持原子操作的情况下。会採用自己封装的mutex来做相互排斥，假设不支持，就使用os_mutex_t。在gcc 4.1.2之前，编译器是
不提供原子操作的API的，所以在MySQL-.3.23的innodb中自己实现了一个类似__sync_lock_test_and_set的实现，代码是採用
了汇编实现：
asm volatile("movl $1, %%eax; xchgl (%%ecx), %%eax" :
"=eax" (res), "=m" (*lw) :
"ecx" (lw));事实上就是将lw的值设置成1,而且返回设置lw之前的值(res),这个过程都是CPU须要回写内存的，也就是CPU和内存是全然一致的。
除了上面设置1以外。另一个复位的实现，例如以下：
asm volatile("movl $0, %%eax; xchgl (%%ecx), %%eax" :
"=m" (*lw) : "ecx" (lw) : "eax"); #define LOCK() while(__sync_lock_test_and_set(&lock, 1)){}
#define UNLOCK() __sync_lock_release(&lock)3 mutex的实现
在innodb中，带有原子操作的mutex自己定义相互排斥量是基础的并发和同步的机制，目的是为了降低CPU的上下文切换和提供高效率。一般mutex等待的时间不超过100微秒的条件下，这样的mutex效率是很高的。假设等待的时间长，建议选择os_mutex方式。尽管自己定义mutex在自旋时间超过自旋阈值会进入信号等待状态。可是整个过程相对os_mutex来说。效率太低。这不是自己定义mutex的目的。自己定义mutex的定义例如以下：
struct mutex_struct
{
ulint lock_word; /*mutex原子控制变量*/
os_fast_mutex_t os_fast_mutex; /*在编译器或者系统部支持原子操作的时候採用的系统os_mutex来替代mutex*/
ulint waiters; /*是否有线程在等待锁*/
UT_LIST_NODE_T(mutex_t) list; /*mutex list node*/
os_thread_id_t thread_id; /*获得mutex的线程ID*/
char* file_name; /*mutex lock操作的文件/
ulint line; /*mutex lock操作的文件的行数*/
ulint level; /*锁层ID*/
char* cfile_name; /*mute创建的文件*/
ulint cline; /*mutex创建的文件行数*/
ulint magic_n; /*魔法字*/
};mutex_enter_func 获得mutex锁，假设mutex被其它线程占用。先会自旋SYNC_SPIN_ROUNDS,然后
再等待占用锁的线程的信号
mutex_exit 释放mutex锁。并向等待线程发送能够抢占mutex的信号量
mutex_exit 释放mutex锁。并向等待线程发送能够抢占mutex的信号量
3.1 mutex_enter_func流程图：
以上流程主要是在mutex_spin_wait这个函数中实现的，从其代码中能够看出，这个函数是尽力让线程在自旋周期内获得锁。由于一旦进入cell_wait状态，至少的耗费1 ~ 2次系统调用。在cell_add的时候有可能触发os_mutex_t的锁等待和一定会event_wait等待。这比系统os_mutex效率会低得多。假设在调试状态下。获得锁的同一时候会向thread_levels的加入一条正在使用锁的信息，以便死锁检查和调试。
3.2 mutex_exit流程图
3.4 mutex_t的内存结构关系图
3.4mutex获得锁和释放锁的示意图
4 rw_lock的实现
innodb为了提高读的性能，自己定义了read write lock。也就是读写锁。其设计原则是：
1、同一时刻同意多个线程同一时候读取内存中的变量
2、同一时刻仅仅同意一个线程更改内存中的变量
3、同一时刻当有线程在读取变量时不同意不论什么线程写存在
4、同一时刻当有线程在更改变量时不同意不论什么线程读，也不同意出自己以外的线程写（线程内能够递归占有锁）。
5、当有rw_lock处于线程读模式下是有线程写等待，这时候假设再有其它线程读请求锁的时。这个读请求将处于等待前面写完毕。
1、同一时刻同意多个线程同一时候读取内存中的变量
2、同一时刻仅仅同意一个线程更改内存中的变量
3、同一时刻当有线程在读取变量时不同意不论什么线程写存在
4、同一时刻当有线程在更改变量时不同意不论什么线程读，也不同意出自己以外的线程写（线程内能够递归占有锁）。
5、当有rw_lock处于线程读模式下是有线程写等待，这时候假设再有其它线程读请求锁的时。这个读请求将处于等待前面写完毕。
从上面5点我们能够看出，rw_lock在被占用是会处于读状态和写状态，我们称之为S-latch(读共享)和X-latch（写独占）。《MySQL技术内幕：innodb引擎》对S-latch和X_latch的描写叙述例如以下：
| S-latch | X-latch | |
| S-latch | 兼容 | 不兼容 |
| X-latch | 不兼容 | 不兼容 |
innodb中的rw_lock是在建立在自己定义mutex_t之上的。全部的控制是基于mutex和thread_cell的。
下面是rw_lock_t的结构定义：
struct rw_lock_struct
{
ulint reader_count; /*获得S-LATCH的读者个数,一旦不为0，表示是S-LATCH锁*/
ulint writer; /*获得X-LATCH的状态。主要有RW_LOCK_EX、RW_LOCK_WAIT_EX、
RW_LOCK_NOT_LOCKED， 处于RW_LOCK_EX表示是一个x-latch
锁,RW_LOCK_WAIT_EX的状态表示是一个S-LATCH锁*/
os_thread_id_t writer_thread; /*获得X-LATCH的线程ID或者第一个等待成为x-latch的线程ID*/
ulint writer_count; /*同一线程中X-latch lock次数*/
mutex_t mutex; /*保护rw_lock结构中数据的相互排斥量*/
ulint pass; /*默觉得0，假设是非0，表示线程能够将latch控制权转移给其它线程，
在insert buffer有相关的调用*/
ulint waiters; /*有读或者写在等待获得latch*/
ibool writer_is_wait_ex;
UT_LIST_NODE_T(rw_lock_t) list;
UT_LIST_BASE_NODE_T(rw_lock_debug_t) debug_list;
ulint level; /*level标示。用于检測死锁*/
/*用于调试的信息*/
char* cfile_name; /*rw_lock创建时的文件*/
ulint cline; /*rw_lock创建是的文件行位置*/
char* last_s_file_name; /*最后获得S-latch时的文件*/
char* last_x_file_name; /*最后获得X-latch时的文件*/
ulint last_s_line; /*最后获得S-latch时的文件行位置*/
ulint last_x_line; /*最后获得X-latch时的文件行位置*/
ulint magic_n; /*魔法字*/
};RW_LOCK_NOT_LOCKED 空暇状态
RW_LOCK_SHARED 处于多线程并发都状态
RW_LOCK_WAIT_EX 等待从S-latch成为X-latch状态
RW_LOCK_EX 处于单线程写状态
下面是这四 种状态迁移示意图：
通过上面的迁徙示意图我们能够非常清楚的了解rw_lock的运作机理，除了状态处理以外，rw_lock还为debug提供了接口。我们能够通过内存关系图来了解他们的关系：
5 死锁检測与调试
innodb除了实现自己定义mutex_t和rw_lock_t以外，还对这两个类型的latch做了调试性死锁检測，
这大大简化了innodb的latch调试，latch的状态和信息在能够实时查看到，但这不过在innodb的调试
版本号中才干看到。
与死锁检測相关的模块主要是mutex level、rw_lock level和sync_cell。latch level相关的定义：
/*sync_thread_t*/
struct sync_thread_struct
{
os_thread_id_t id; /*占用latch的thread的id*/
sync_level_t* levels; /*latch的信息，sync_level_t结构内容*/
};
/*sync_level_t*/
struct sync_level_struct
{
void* latch; /*latch句柄，是mute_t或者rw_lock_t的结构指针*/
ulint level; /*latch的level标识ID*/
};在latch获得的时候，innodb会调用mutex_set_debug_info函数向sync_thread_t中增加一个latch被获得的状态信息。事实上就是包含获得latch的线程id、获得latch的文件位置和latch的层标识（详细的细节能够查看mutex_enter_func和mutex_spin_wait）。仅仅有占用了latch才会体如今sync_thread_t中，假设仅仅是在等待获得latch是不会增加到sync_thread_t其中的。innodb能够通过sync_thread_levels_empty_gen函数来输出全部latch等待依赖的cell_t序列。追踪线程等待的位置。
5.1sync_thread_t与sync_level_t的内存结构关系:
sync_thread_level_arrays的长度是OS_THREAD_MAX_N（linux下默认是10000），也就是和最大线程个数是一样的。
levels的长度是SYNC_THREAD_N_LEVELS（10000）。
5.2死锁与死锁检測
什么是死锁，通过下面的样例我们能够做个简单的描写叙述：
线程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在等线程就造成了死锁。
线程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參
1、将进入等待的latch相应的cell作为參数传入到sync_array_detect_deadlock其中，其中start的參数和依赖的cell參
数填写的都是这个cell自己。
2、进入sync_array_detect_deadlock先推断依赖的cell是否正在等待latch,假设没有，表示没有死锁。直接返回.
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.