信号量与互斥锁

http://blog.csdn.net/rommi/article/details/6015143

互斥量(Mutex)

 互斥量表现互斥现象的数据结构，也被当作二元信号灯。一个互斥基本上是一个多任务敏感的二元信号，它能用作同步多任务的行为，它常用作保护从中断来的临界段代码并且在共享同步使用的资源。

 

Mutex本质上说就是一把锁，提供对资源的独占访问，所以Mutex主要的作用是用于互斥。Mutex对象的值，只有0和1两个值。这两个值也分别代表了Mutex的两种状态。值为0, 表示锁定状态，当前对象被锁定，用户进程/线程如果试图Lock临界资源，则进入排队等待；值为1，表示空闲状态，当前对象为空闲，用户进程/线程可以Lock临界资源，之后Mutex值减1变为0。

Mutex可以被抽象为四个操作：

- 创建 Create

- 加锁 Lock

- 解锁 Unlock

- 销毁 Destroy

Mutex被创建时可以有初始值，表示Mutex被创建后，是锁定状态还是空闲状态。在同一个线程中，为了防止死锁，系统不允许连续两次对Mutex加锁(系统一般会在第二次调用立刻返回)。也就是说，加锁和解锁这两个对应的操作，需要在同一个线程中完成。

不同操作系统中提供的Mutex函数:

动作/系统

Win32

Linyx

Solaris

创建

CreateMutex

pthread_mutex_init

mutex_init

加锁

WaitForSingleObject

pthread_mutex_lock

mutex_lock

解锁

ReleaseMutex

pthread_mutex_unlock

mutex_unlock

销毁

CloseHandle

pthread_mutex_destroy

mutex_destroy

 

 

死锁主要发生在有多个依赖锁存在时, 会在一个线程试图以与另一个线程相反顺序锁住互斥量时发生. 如何避免死锁是使用互斥量应该格外注意的东西。

　　总体来讲, 有几个不成文的基本原则:

　　对共享资源操作前一定要获得锁。

　　完成操作以后一定要释放锁。

　　尽量短时间地占用锁。

　　如果有多锁, 如获得顺序是ABC连环扣, 释放顺序也应该是ABC。

　　线程错误返回时应该释放它所获得的锁。

 

也许还有读者好奇，“挂起等待”和“唤醒等待线程”的操作如何实现？每个Mutex有一个等待队列，一个线程要在Mutex上挂起等待，首先在把自己加入等待队列中，然后置线程状态为睡眠，然后调用调度器函数切换到别的线程。一个线程要唤醒等待队列中的其它线程，只需从等待队列中取出一项，把它的状态从睡眠改为就绪，加入就绪队列，那么下次调度器函数执行时就有可能切换到被唤醒的线程。

 

一般情况下，如果同一个线程先后两次调用lock，在第二次调用时，由于锁已经被占用，该线程会挂起等待别的线程释放锁，然而锁正是被自己占用着的，该线程又被挂起而没有机会释放锁，因此就永远处于挂起等待状态了，这叫做死锁（Deadlock）。另一种典型的死锁情形是这样：线程A获得了锁1，线程B获得了锁2，这时线程A调用lock试图获得锁2，结果是需要挂起等待线程B释放锁2，而这时线程B也调用lock试图获得锁1，结果是需要挂起等待线程A释放锁1，于是线程A和B都永远处于挂起状态了。不难想象，如果涉及到更多的线程和更多的锁，有没有可能死锁的问题将会变得复杂和难以判断。

 

信号量

信号量(Semaphore)，有时被称为信号灯，是在多线程环境下使用的一种设施, 它负责协调各个线程, 以保证它们能够正确、合理的使用公共资源。

信号量可以分为几类：

² 二进制信号量(binary semaphore)：只允许信号量取0或1值，其同时只能被一个线程获取。

² 整型信号量（integer semaphore)：信号量取值是整数，它可以被多个线程同时获得，直到信号量的值变为0。

² 记录型信号量（record semaphore)：每个信号量s除一个整数值value（计数）外，还有一个等待队列List，其中是阻塞在该信号量的各个线程的标识。当信号量被释放一个，值被加一后，系统自动从等待队列中唤醒一个等待中的线程，让其获得信号量，同时信号量再减一。

信号量通过一个计数器控制对共享资源的访问，信号量的值是一个非负整数，所有通过它的线程都会将该整数减一。如果计数器大于0，则访问被允许，计数器减1；如果为0，则访问被禁止，所有试图通过它的线程都将处于等待状态。

计数器计算的结果是允许访问共享资源的通行证。因此，为了访问共享资源，线程必须从信号量得到通行证， 如果该信号量的计数大于0，则此线程获得一个通行证，这将导致信号量的计数递减，否则，此线程将阻塞直到获得一个通行证为止。当此线程不再需要访问共享资源时，它释放该通行证，这导致信号量的计数递增，如果另一个线程等待通行证，则那个线程将在那时获得通行证。

 

 

Semaphore可以被抽象为五个操作：

- 创建 Create

- 等待 Wait：

线程等待信号量，如果值大于0，则获得，值减一；如果只等于0，则一直线程进入睡眠状态，知道信号量值大于0或者超时。

-释放 Post

执行释放信号量，则值加一；如果此时有正在等待的线程，则唤醒该线程。

-试图等待 TryWait

如果调用TryWait，线程并不真正的去获得信号量，还是检查信号量是否能够被获得，如果信号量值大于0，则TryWait返回成功；否则返回失败。

-销毁 Destroy

信号量，是可以用来保护两个或多个关键代码段，这些关键代码段不能并发调用。在进入一个关键代码段之前，线程必须获取一个信号量。如果关键代码段中没有任何线程，那么线程会立即进入该框图中的那个部分。一旦该关键代码段完成了，那么该线程必须释放信号量。其它想进入该关键代码段的线程必须等待直到第一个线程释放信号量。为了完成这个过程，需要创建一个信号量，然后将Acquire Semaphore VI以及Release Semaphore VI分别放置在每个关键代码段的首末端。确认这些信号量VI引用的是初始创建的信号量。

动作/系统

Win32

POSIX

创建

CreateSemaphore

sem_init

等待

WaitForSingleObject

sem _wait

释放

ReleaseMutex

sem _post

试图等待

WaitForSingleObject

sem _trywait

销毁

CloseHandle

sem_destroy

 

 (生产者 消费者)

 

互斥量和信号量的区别

1.互斥量用于线程的互斥，信号线用于线程的同步。

这是互斥量和信号量的根本区别，也就是互斥和同步之间的区别。

互斥：是指某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性或者说互斥性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的。

同步：是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问，是流程上的概念。比如：有A,B两个线程，B线程要等A线程完成某一任务以后再进行自己下面的步骤，这个任务并不一定是锁定某一资源，还可以是进行一些计算或者数据处理之类，给B线程的处理做准备。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源

2.互斥量值只能为0/1，信号量值可以为非负整数。

也就是说，一个互斥量只能用于一个资源的互斥访问，它不能实现多个资源的多线程互斥问题。信号量可以实现多个同类资源的多线程互斥和同步。当信号量为单值信号量时，也可以完成一个资源的互斥访问。

3.互斥量的加锁和解锁必须由同一线程分别对应使用，信号量可以由一个线程释放，另一个线程得到。

上锁时 
信号量: 只要信号量的value大于0，其他线程就可以sem_wait成功，成功后信号量的value减一。若value值不大于0，则sem_wait阻塞，直到sem_post释放后value值加一。一句话，信号量的value>=0。 
互斥锁: 只要被锁住，其他任何线程都不可以访问被保护的资源。如果没有锁，获得资源成功，否则进行阻塞等待资源可用。一句话，线程互斥锁的vlaue可以为负数。

信号量和线程互斥锁的实现机制

在Linux下，信号量和线程互斥锁的实现都是通过futex系统调用。 

futex（快速用户区互斥的简称）是一个在Linux上实现锁定和构建高级抽象锁如信号量和POSIX互斥的基本工具。它们第一次出现在内核开发的2.5.7版；其语义在2.5.40固定下来，然后在2.6.x系列稳定版内核中出现。 

Futex 是fast userspace mutex的缩写，意思是快速用户空间互斥体。Linux内核把它们作为快速的用户空间的锁和信号量的预制构件提供给开发者。Futex非常基础，借助其自身的优异性能，构建更高级别的锁的抽象，如POSIX互斥体。大多数程序员并不需要直接使用Futex，它一般用来实现像NPTL这样的系统库。 

Futex 由一块能够被多个进程共享的内存空间（一个对齐后的整型变量）组成；这个整型变量的值能够通过汇编语言调用CPU提供的原子操作指令来增加或减少，并且一个进程可以等待直到那个值变成正数。Futex 的操作几乎全部在应用程序空间完成；只有当操作结果不一致从而需要仲裁时，才需要进入操作系统内核空间执行。这种机制允许使用 futex 的锁定原语有非常高的执行效率：由于绝大多数的操作并不需要在多个进程之间进行仲裁，所以绝大多数操作都可以在应用程序空间执行，而不需要使用（相对高代价的）内核系统调用。 

futex保存在用户空间的共享内存中，并且通过原子操作进行操作。在大部分情况下，资源不存在争用的情况下，进程或者线程可以立刻获得资源成功，实际上就没有必要调用系统调用，陷入内核了。实际上，futex的作用就在于减少系统调用的次数，来提高系统的性能。

线程互斥锁pthread_mutex_t的实现原理： 

pthread_mutex_lock:  atomic_dec(pthread_mutex_t.value);  if(pthread_mutex_t.value!=0)     futex(WAIT)  else     success    pthread_mutex_unlock:  atomic_inc(pthread_mutex_t.value);  if(pthread_mutex_t.value!=1)     futex(WAKEUP)  else     success  

信号量sem_t的实现原理（直接从glibc/nptl/DESIGN-sem.txt中摘的）： 

sem_wait(sem_t *sem)  {    for (;;) {        if (atomic_decrement_if_positive(sem->count))        break;        futex_wait(&sem->count, 0)    }  }    sem_post(sem_t *sem)  {    n = atomic_increment(sem->count);    // Pass the new value of sem->count    futex_wake(&sem->count, n + 1);  

对比，pthread_mutex_unlock()和sem_post()的实现，我们发现一个不同点，sem_post()无论如何都会调用futex_wake()，进行系统调用。但是pthread_mutex_unlock()却符合futex的初衷，只有在需要仲裁的时候才调用futex_wake()。那么什么是仲裁条件呢？ 

前面说过信号量和线程互斥锁语义上的区别在于信号量的value>=0，而线程互斥锁的value可以为负数。 
对于lock操作，这两个倒是没有多少差别。信号量只要value>0就可以获得资源，线程互斥锁需要value=1。 
但是对于unlock操作，这两个就有一些差别了。信号量和线程互斥锁，都会增加对应的value。如果加1后，value为1，对于线程互斥锁来讲，实际上表明资源可用，并且之前没有其他的线程在等待这个资源；否则说明还有其他线程在等待这个资源，需要调用futex系统调用唤醒它们。但是对于信号量，由于value必须>=0。那么加1后，即使value为1，也无法判定现在没有其他的进程或线程正在等待资源，所以必须调用futex系统调用。例如： 

#include <stdio.h>  #include <semaphore.h>  #include <pthread.h>    sem_t sem_a;  void *task1();    int main(void)  {   int ret=0;   pthread_t thrd1;   pthread_t thrd2;   sem_init(&sem_a,0,1);   ret=pthread_create(&thrd1,NULL,task1,NULL); //创建子线程   ret=pthread_create(&thrd2,NULL,task1,NULL); //创建子线程   pthread_join(thrd1,NULL); //等待子线程结束   pthread_join(thrd2,NULL); //等待子线程结束  }    void *task1()  {    int sval = 0;    sem_wait(&sem_a); //持有信号量    sleep(5); //do_nothing    sem_getvalue(&sem_a,&sval);    printf("sem value = %d\n",sval);    sem_post(&sem_a); //释放信号量  }   

上面sem的value初始化为1，但是有两个线程争用资源。那么第一个线程获得资源成功，当它unlock的时候，sem的value变为1。但是，这个时候，实际上还有一个线程在等待资源。因此，必须要进行futex_wake()系统调用，唤醒等待资源的线程。 

感兴趣的同学可以使用strace跟踪一下，进行验证。要注意忽略程序运行初始化的那个futex_wake ;-) 

参考：http://jimmee.iteye.com/blog/618740