深刻理解Linux用户空间的锁机制

1.         缘起 

随着SMP(Symmetrical Multi-Processing)架构的流行和epoll类系统调用对非阻塞fd监视的支持，高性能服务器端的开发已经可以实现CPU计算和IO的分离。为了充分发挥CPU的计算能力，服务器端的设计必需要尽可能减小线程切换。引发线程切换最重要的缘由之一就是对mutex和semaphor等锁的使用。本文从计算机体系架构、操做系统的支持和mutex的实现完全分析Linux用户空间mutex的实现，分析的源码版本是glib-2.3.4和kernel-2.6.8。  

2.         体系结构和指令的支持 

在UP(uni processor)架构下，从用户空间的角度看，中断打断了程序的正常执行。操做系统在处理完中断以后，返回用户空间的以前，从新调度系统中的线程执行。因为CPU是在执行汇编指令结束后响应中断，那么单条汇编指令的执行就是原子的。  

在SMP下，因为存在CPU Local Cache和每一个CPU的指令周期不一样，单条汇编指令的执行不会是原子的。X86 SMP提供了一个lock指令前缀，使得某些汇编指令的执行是原子的。看以下x86_64体系结构的汇编代码，来自glibc。  

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2中对cmpxchg指令的解释以下：  

This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.  

全部以lock为前缀的指令都起内存栅栏的做用。内存栅栏使编译器确保对RAM中数据的改变对全部CPU都是可见的。  

上述汇编对应的伪代码：  

   

 Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2中对cmpxchg指令的解释以下：  

This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.  

 

 

 

by gaolingfei   

全部以lock为前缀的指令都起内存栅栏的做用。内存栅栏使编译器确保对RAM中数据的改变对全部CPU都是可见的。  

上述汇编对应的伪代码：  

  

 

 

3.         操做系统支持   

按照操做系统的经典定义，进程是资源分配的最小单位，线程是调度的最小单位。 Linux操做系统提供了 futex系统调用以支持 mutex等锁的实现。 futex的主要功能是使得线程以 TASK_INTERRUPTIBLE状态等待处于进程空间的某变量的改变，或者使得某线程能够唤醒等待该变量的其余线程。  

2.6.8版的 Kernel中， futex的实现使用一个 futex_hash_bucket。操做系统用户空间任何线程若是在等待mutex或者semaphore的up操做，都是以每一个锁的address等为key，将自身线程挂到该futex_hash_bucket等待被唤醒。  

实现 wait的步骤以下：  

A.        down_read获得当前线程整个地址空间的读锁，从该步起到 up_read，与线程同一个进程的其余线程mmap()和brk()系统调用都会挂起，mmap()和brk()是malloc()和free()的基础。  ()(& current->mm->mmap_sem);

B.        调用 find_extend_vma以确认用户空间锁的地址是不是shared or private mapping. shared mapping通常是进程有多个线程引发的。 find_extend_vma会搜索整个进程地址空间段组成红黑树，以肯定该地址空间的类型。  ()(),

C.        计算 key。若是是单进程单线程， Key为用户空间地址。若是为单进程多线程，须要执行 spin_lock获得用户地址对应的page，而后 spin_unlock。 page_table_lock会影响相应进程的page fault的处理。  (& current->mm->page_table_lock)(& current->mm->page_table_lock);

D.        将自身线程加入到 futex_hash_bucket， futex_hash_bucket的每一个桶有一个spin lock保护。  

E.         up_read  (& current->mm->mmap_sem);

F.         __set_current_state  ( TASK_INTERRUPTIBLE);

G.        __set_current_state此时线程已经被其余线程唤醒。  ( TASK_RUNNING);

H.        将自身从 futex_hash_bucket移除。  

实现 wake up的步骤以下：  

A.        执行 wait的 A到 C。  

B.        spin_lock给相应桶加锁。  (&bh-> lock);

C.        唤醒在锁上的一个等待线程。  

D.        spin_unlock  (&bh-> lock);

E.         up_read  (& current->mm->mmap_sem);

4.         pthread_mutex 实现分析   

pthread_mutex_lock()实如今 glibc-2.3.4 pthread_mutex_lock.c文件的 33行，该函数会根据 mutex在 init的时候设置的属性，选择不一样的执行路径。 mutex的属性有四种：  

A.        PTHREAD_MUTEX_TIMED_NP：默认属性。 pthread_mutex_lock()直接调用 lll_mutex_lock()。  

B.        PTHREAD_MUTEX_RECURSIVE_NP：检查 mutex owner 是否为当前线程。该属性容许线程屡次获取该锁。  

C.        PTHREAD_MUTEX_ERRORCHECK_NP：若是同一线程两次 lock，会返回错误。  

D.        PTHREAD_MUTEX_ADAPTIVE_NP：该锁会先 n次调用 lll_mutex_trylock()， n为用户定义和 100的最小值。若是仍然失败，则调用 lll_mutex_lock()。 lll_mutex_trylock()不会调用 futex。  

5.         spin lock 实现   

nginx实现了 spin lock以保护多进程对 listen port的互斥 accept。 spinlock的实现以下：  

 

 

 

Spinlock本质上是一个“忙等”锁，因为其不存在下节中总结的 mutex的缺点，其对于小资源是最高效的锁。相比上节中 mutex的 PTHREAD_MUTEX_ADAPTIVE_NP属性， nginx的 spinlock是一个更完美的实现方案。  

 

6.         总结  

在设置 PTHREAD_MUTEX_TIMED_NP属性和单进程多线程模型下， pthread_mutex_lock()对同进程的其余线程的影响以下：  

A.        pthread_mutex_lock()占用的大部分 CPU时间当中，直接影响其余线程调用 mmap()， brk()， malloc和 free()。  

B.        对进程处理 page fault也会有影响。  

C.        若是整个操做系统的用户进程使用了过多的 mutex之类的锁，那么全部锁共享的 futex_hash_bucket将是一个瓶颈。  

D.        最重要的是，锁的使用会引发线程的频繁切换，致使 cpu cache miss和 TLB miss。  

对于系统中，须要互斥访问的资源，以下建议：  

A.        内核中对于小资源如链表的增删，可能是使用 spin lock保护。  

B.        在设置 PTHREAD_MUTEX_ADAPTIVE_NP属性下， mutex既能够是 spin lock，也能够是阻塞锁。  

C.        使用 atomic_add_return(i, v)，原子对变量 i增长 v值，而且返回操做后的值。相反操做： atomic_sub_return(i, v)。  

D.        使用 Per-CPU variables，例如多线程程序中要每隔 1秒，统计某项操做的值。该变量最好是 cache alignment。  

E.         对于如数据库频繁更新的操做，可使用数据库的多版本并发控制方法减小对 mutex的 lock。