MySQL源代码：如何对读写锁进行处理

最近碰到一个问题，线上一台机器在等待信号量时间过长，mysql的监控线程认为此时mysqld已经hang住了，于是自杀重启。这里涉及到一

最近碰到一个问题，线上一台机器在等待信号量时间过长，，mysql的监控线程认为此时mysqld已经hang住了，于是自杀重启。这里涉及到一个有趣的问题，也就是mysql如何对读写锁进行处理。

主要包括三个部分：

1. 建锁

2. 加锁

3. 解锁

4. 监控锁

 以下内容基于Percona5.5.18进行分析

 

1.创建锁

锁的创建实际上就是初始化一个RW结构体（rw_lock_t），实际调用函数如下:

[cpp]

# define rw_lock_create(K, L, level)                                 \   

         rw_lock_create_func((L),#L)  

在rw_lock_create上有三个参数，在实际场景锁时只用到第2个参数

其中K表示mysql_pfs_key_t，level显示当前的操作类型（起码看起来是的，在文件sync0sync.h中定义），看起来k是为performance schema准备的，而k代表了当前操作所在的层次。

例如：purge线程的读写锁创建：

[html]

rw_lock_create(trx_purge_latch_key,  

我们进去rw_lock_create_func看看到底是怎么创建的。

可以看到这个函数的逻辑其实很简单：

lock->lock_word =X_LOCK_DECR;    //关键字段

用于限制读写锁的最大并发数，代码里的注释如下：

[cpp]

在尝试加锁时会调用rw_lock_lock_word_decr减少lock_word

 在初始化一系列变量后，执行：

[cpp]

lock->event = os_event_create(NULL);  

lock->wait_ex_event = os_event_create(NULL);  

os_event_create用于创建一个系统信号，实际上最终创建的还是互斥量（os_fast_mutex_init(&(event->os_mutex));以及条件变量（os_cond_init(&(event->cond_var));）

最后将lock加入到全局链表rw_lock_list中