在rw_lock_s_lock_spin里会递归的调用到rw_lock_s_lock_low函数；
看起来实际的加锁和解锁操作是通过对计数器来控制的，
(1)在函数rw_lock_s_lock_low中
rw_lock_lock_word_decr (lock, 1)，对lock->lock_word减去1
减数成功返回true，否则返回false
这部分的逻辑还是很简单的。
(2)在函数rw_lock_x_lock_low中，调用：
rw_lock_lock_word_decr(lock, X_LOCK_DECR)，对lock->lock_word减去X_LOCK_DECR
减数成功后，执行：
rw_lock_set_writer_id_and_recursion_flag(lock,pass FALSE : TRUE)来设置：
lock->writer_thread = s_thread_get_curr_id()
lock->recursive = TRUE
然后调用rw_lock_x_lock_wait函数等待lock->lock_word=0，也就是说等待所有的读锁退出。
看到一个比较有意思的现象，在.ic的代码里看到使用了宏
INNODB_RW_LOCKS_USE_ATOMICS，这是跟gcc的版本相关的，通过使用gcc的内建函数来实现原子操作。
3.解锁
解锁操作包括解除读锁（#define rw_lock_s_unlock(L) rw_lock_s_unlock_gen(L, 0)）和解除写锁操作（#definerw_lock_x_unlock(L) rw_lock_x_unlock_gen(L, 0)）
实际调用函数为rw_lock_s_unlock_func和rw_lock_x_unlock_func
1)解除读锁（rw_lock_s_unlock_func）
增加计数rw_lock_lock_word_incr(lock, 1)
2)解除写锁（rw_lock_x_unlock_func）
执行如下操作
(1)如果是最后一个递归调用锁的线程，设置lock->recursive= FALSE; 代码里的注释如下：
/* lock->recursive flag also indicatesif lock->writer_thread is
valid or stale. If we are the last of the recursive callers
then we must unset lock->recursive flag to indicate that the
lock->writer_thread is now stale.
Note that since we still hold the x-lock we can safely read the
lock_word. */
(2)增加计数rw_lock_lock_word_incr(lock,X_LOCK_DECR) == X_LOCK_DECR，这时候需要向等待锁的线程发送信号：
if (lock->waiters) {
rw_lock_reset_waiter_flag(lock);
os_event_set(lock->event);
sync_array_object_signalled(sync_primary_wait_array);
}
os_event_set函数会发送一个pthread_cond_broadcast给等待的线程
4.监控读写锁
为了防止mysqld被hang住导致的长时间等待rw锁，error监控线程会对长时间等待的线程进行监控。这个线程每1秒loop一次
（os_event_wait_time_low(srv_error_event, 1000000, sig_count);）
函数入口：srv_error_monitor_thread
函数sync_array_print_long_waits()用于处理长时间等待信号量的线程，流程如下：
1. 查看sync_primary_wait_array数组中的所有等待线程。
->大于240秒时，向错误日志中输出警告，设置noticed = TRUE;
->大于600秒时，设置fatal =TRUE;
2.当noticed为true时，打印出innodb监控信息，然后sleep30秒
3. 返回fatal值
当函数sync_primary_wait_array返回true时，对于同一个等待线程还会有十次机会，也就是300 + 1*10（监控线程每次loop sleep 1s）秒的时间；如果挺不过去，监控线程就会执行一个断言失败：
if (fatal_cnt > 10) {
fprintf(stderr,
"InnoDB:Error: semaphore wait has lasted"
"> %lu seconds\n"
"InnoDB:We intentionally crash the server,"
"because it appears to be hung.\n",
(ulong) srv_fatal_semaphore_wait_threshold);
ut_error;
}
ut_error是一个宏：
#define ut_error assert(0)
断言失败导致mysqld crash
在函数srv_error_monitor_thread里发现一个比较有意思的参数srv_kill_idle_transaction，对应的系统变量为innodb_kill_idle_transaction，用于清理在一段时间内的空闲事务。这个变量指定了空闲事务的最长时间。具体实现分析，且听下回分解
作者 记录成长之路