【Java并发编程】synchronized（四）：信号量、互斥量原理分析对比

ゝ一世哀愁。 2022-12-08 01:38 215阅读 0赞

## 1.信号量 ##

信号量是用来协调不同进程间的数据对象的，而最主要的应用是共享内存方式的进程间通信。本质上，**信号量是一个计数器**，它用来记录对某个资源（如共享内存）的存取状况。

一般说来，为了获得共享资源，进程需要执行下列操作：

1.  测试控制该资源的信号量
2.  若此信号量的值为正，则允许进行使用该资源。进程将信号量减 1
3.  若此信号量为 0，则该资源目前不可用，进程进入睡眠状态，直至信号量值大于0，进程被唤醒，转入步骤 1
4.  当进程不再使用一个信号量控制的资源时，信号量值加1。如果此时有进程正在睡眠等待此信号量，则唤醒此进程

### 1.1 Semaphore 结构 ###

维护信号量状态的是 Linux 内核操作系统而不是用户进程。我们可以从头文件 /usr/src/linux/include/linux/sem.h 中看到内核用来维护信号量状态的各个结构的定义。信号量是一个数据集合，用户可以单独使用这一集合的每个元素。要调用的第一个函数是 semget，用以获得一个信号量 ID。

Linux2.6.26 下定义的信号量结构体：

struct semaphore {
        
        spinlock_t lock; // 自旋锁
        unsigned int count; // 计数
        struct list_head wait_list; // 等待队列（保存休眠的进程）
    };

从以上信号量的定义中，可以看到信号量底层使用到了 spin lock 的锁定机制，这个 spinlock 主要用来确保对 count 成员的原子性的操作(count–)和测试(count > 0)。

> PS：从 semaphore 的结构也可以看出来，实现一个锁的本质就是，**计数器 = 计数 + 保证线程安全 + 等待队列**
> 
> 1.  申请资源时，count–，如果申请不到就放入条件队列中休眠
> 2.  释放资源时，count++，如果等待队列中有等待唤醒的进程，就唤醒一个进程再来申请资源（一般是队列中第一个）
> 
> JUC 的 AQS 的结构及实现原理基本就是这样，只不过在保证它除了有同步队列还有个条件队列。

### 1.2 P 操作原理 ###

P 操作就是其实就是申请获取资源（lock，加锁）。

相关函数如下：

void up(struct semaphore *sem)；

up 的源码如下：

void up(struct semaphore *sem)
    {
        
        unsigned long flags;
        spin_lock_irqsave(&sem->lock, flags);
        // 如果没有其他线程等待在目前即将释放的信号量上，那么只需将 count++ 即可
        if (likely(list_empty(&sem->wait_list)))
                sem->count++;
        // 如果有其他线程正因为等待该信号量而睡眠，那么调用__up唤醒
        else
                __up(sem);
        spin_unlock_irqrestore(&sem->lock, flags);
    }

\_\_up 的定义：

static noinline void __sched __up(struct semaphore *sem)
    {
        	
    	// 首先获得sem所在的wait_list为头部的链表的第一个有效节点
        struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list, struct semaphore_waiter, list);
        // 然后从链表中将其删除
        list_del(&waiter->list);
        waiter->up = 1;
        // 然后唤醒该节点上睡眠的进程
        wake_up_process(waiter->task);
    }

由此可见，对于 sem 上的每次 down\_interruptible 调用，都会在sem的wait\_list链表尾部加入一新的节点。对于sem上的每次up调用，都会删除掉wait\_list链表中的第一个有效节点，并唤醒睡眠在该节点上的进程。

### 1.4 信号量使用示例 ###

信号量使用流程：

// 1.分配信号量对象
    struct semaphore sema;
    
    // 2.初始化为互斥信号量
    init_MUTEX(&sema);
    或者：
    DECLARE_MUTEX(sema);
    
    // 3.访问临界区之前获取信号量
    down(&sema); // 如果获取到信号量，立即返回。如果信号量不可用，进程将在此休眠，并且休眠的状态是[不可中断的休眠状态 TASK_UNINTERRUPTIBLE]
    或者
    down_interruptible(&sema); // 如果信号量不可用，进程将进入[可中断的休眠状态 TASK_INTERRUPTIBLE]，如果返回0表示正常获取信号，如果返回非0，表示接受到了信号
    或者
    down_trylock(); // 获取信号，如果信号量不可用，返回非0，如果信号量可用，返回0；不会引起休眠，可以在中断上下文使用。返回值也要做判断
      
    // 4.访问临界区：临界区可以休眠
    
    // 5.释放信号量
    up(&sema);  // 不仅仅释放信号量，然后唤醒休眠的进程，让这个进程去获取信号量来访问临界区

下面举一个生产者消费者的例子：

item buffer[n]; // n个缓冲区组成的数组;
    int in = 0, out = 0; // in: 输入指针, out: 输出指针;
    
    // 信号量不允许直接参与运算, 故都要定义;
    semaphore mutex = 1; // mutex: 互斥信号量, 生产者进程和消费者进程都只能互斥访问缓冲区;
    semaphore full = 0;  // full: 资源信号量, 满缓冲区的数量;
    semaphore empty = n; // empty: 资源信号量, 空缓冲区的数量;
    
    // 生产者程序;
    void Producer() {
        
      do {
        
          生产者生产一个产品nextp;
          P(empty); // 申请一个空缓冲区;
          P(mutex); // 申请临界资源;
          buffer[in] = nextp; // 将产品添加到缓冲区;
          in = (in + 1) % n;  // 类似于循环队列;
          V(mutex); // 释放临界资源;
          V(full);  // 释放一个满缓冲区;
      } while (TRUE);
    }
     
    // 消费者程序;
    void Producer() {
        
      do {
        
          P(full);  // 申请一个满缓冲区;
          P(mutex); // 申请临界资源;
          nextc = buffer[out]; // 将产品从缓冲区取出;
          out = (out + 1) % n; // 类似于循环队列;
          V(mutex); // 释放临界资源;
          V(empty); // 释放一个空缓冲区;
          消费者将一个产品nextc消费; 
     } while (TRUE);
    }

需要注意的是：应**先执行对资源信号量的申请，然后再对互斥信号量进行申请操作**，否则会因起死锁。

首先缓冲区有n个，每个都有满（full）和和空（empty）的两种状态，临界区只有一个，控制权为mutex,值为1

1.  如果生产者首先拿到的是缓冲区的控制权，那么其他的生产者和消费者就拿不到这个控制权了
2.  接着这个生产者去申请一个空的缓冲区，如果此时这些个缓冲区刚好是满的，那么这个申请必然失败
3.  那么消费者还能消费吗？他拿不到临界区的控制权，无法消费，也就没有空的缓冲区腾出来，生产者申请空缓冲区也必然不成功，此时就是一个死锁的状态了。

更多互斥量示例可以参考[这篇文章][Link 1]…

## 2 互斥量 ##

互斥体实现了“互相排斥”（mutual exclusion）同步的简单形式（所以名为互斥体(mutex)）。互斥体禁止多个线程同时进入受保护的代码“临界区”（critical section）。因此，在任意时刻，只有一个线程被允许进入这样的代码保护区。

任何线程在进入临界区之前，必须获取（acquire）与此区域相关联的互斥体的所有权。如果已有另一线程拥有了临界区的互斥体，其他线程就不能再进入其中。这些线程必须等待，直到当前的属主线程释放（release）该互斥体。

### 2.1 Mutex 结构 ###

Linux 2.6.26 中 mutex 的定义：

struct mutex {
        
            /* 1: unlocked, 0: locked, negative: locked, possible waiters */
            atomic_t                  count;
            spinlock_t                wait_lock;
            struct list_head          wait_list;
    #ifdef CONFIG_DEBUG_MUTEXES
            struct thread_info        *owner;
            const char                *name;
            void                      *magic;
    #endif
    #ifdef CONFIG_DEBUG_LOCK_ALLOC
            struct lockdep_map         dep_map;
    #endif
    };

对比前面的 struct semaphore，struct mutex 除了增加了几个作为 debug 用途的成员变量外，和 semaphore 几乎长得一样。但是mutex 的引入主要是为了提供互斥机制，以避免多个进程同时在一个临界区中运行。

*  如果静态声明一个 count=1 的 semaphore 变量，可以使用`DECLARE_MUTEX(name)`
 *  如果要定义一个静态 mutex 型变量，应该使用 `DEFINE_MUTEX`

如果在程序运行期要初始化一个mutex变量，可以使用mutex\_init（mutex），mutex\_init是个宏，在该宏定义的内部，会调用\_\_mutex\_init函数。

#define mutex_init(mutex) \
    do { \
        static struct lock_class_key __key; \
        \
        __mutex_init((mutex), #mutex, &__key); \
    } while (0)
      
    void __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)
    {
        
        atomic_set(&lock->count, 1);
        spin_lock_init(&lock->wait_lock);
        INIT_LIST_HEAD(&lock->wait_list);
        debug_mutex_init(lock, name, key);
      
    }

从\_\_mutex\_init的定义可以看出，在使用mutex\_init宏来初始化一个mutex变量时，应该使用mutex的指针型。

### 2.2 互斥量的 PV 操作 ###

void mutex_lock(struct mutex *lock);
    void __sched mutex_unlock(struct mutex *lock);

从原理上讲，mutex实际上是count=1情况下的semaphore，所以其PV操作应该和semaphore是一样的。但是在实际的Linux代码上，出于性能优化的角度，并非只是单纯的重用down\_interruptible和up的代码。

以 ARM 平台的 mutex\_lock 为例，实际上是将 mutex\_lock 分成两部分实现：fast path和slow path，主要是基于这样一个事实：在绝大多数情况下，试图获得互斥体的代码总是可以成功获得。所以 Linux 的代码针对这一事实用 ARM V6 上的 LDREX 和 STREX 指令来实现 fast path 以期获得最佳的执行性能。

mutux 底层支持：

1） Linux：底层的 pthread mutex采用futex(2)（fast userspace mutex）实现，不必每次加锁、解锁都陷入系统调用（从用户态切换到内核态）。

> futex(2)：快速用户态互斥锁（fast userspace mutex），在非竞态（或非锁争用，表示申请即能立即拿到锁而不用等待）的情况下，futex操作完全在用户态下进行，内核态只负责处理竞态（或锁争用，表示申请了但有其它线程提前拿到了锁，需要等待锁被释放后才能拿到）下的操作（调用相应的系统调用来仲裁），futex有两个主要的函数：
> 
>     futex_wait(addr, val) // 检查*addr == val ?，若相等则将当前线程放入等待队列addr中随眠（陷入到内核态等待唤醒），否则调用失>败并返回错误（依旧处于用户态）
>     futex_wake(addr, val) // 唤醒val个处于等待队列addr中的线程（从内核态回到用户态
> 
> 因此采用futex(2)的互斥锁不必每次加解锁都从用户态切换到内核态，效率较高.

2）Windows：底层的 CRITICAL\_SECTION 嵌入了一小段自旋锁，如果不能立即拿到锁，它先会自旋一小段时间，如果还拿不到，才挂起当前线程.

### 2.3 互斥量使用示例 ###

互斥量使用流程：

#include<pthread.h> // 以下方法都是成功返回0，失败返回-1
    
    int pthread_mutex_init(pthread_mutex_t *mutex,pthread_mutexattr *attr);  // 初始化锁
    
    int pthread_mutex_lock(pthread_mutex_t *mutex);   // 对资源加锁，阻塞。
    int pthread_mutex_trylock(pthread_mutex_t*mutex); // 对资源加锁，非阻塞
    
    // 临界区...
    // 临界区...
    
    int pthread_mutex_unlock(pthread_mutex_t *mutex);  // 对资源解锁
    
    int pthread_mutex_destroy(pthread_mutex_t *mutex);  // 销毁锁

## 3.互斥量和信号量区别 ##

1）概念上的区别：

*  信号量：是进程间（线程间）同步用的，一个进程（线程）完成了某一个动作就通过信号量告诉别的进程（线程），别的进程（线程）再进行某些动作。有二值和多值信号量之分。
 *  互斥锁：是线程间互斥用的，一个线程占用了某一个共享资源，那么别的线程就无法访问，直到这个线程离开，其他的线程才开始可以使用这个共享资源。可以把互斥锁看成二值信号量。

2）上锁时：

*  信号量: 只要信号量的 value 大于0，其他线程就可以 sem\_wait 成功，成功后信号量的 value 减一。若value值不大于0，则sem\_wait阻塞，直到sem\_post释放后value值加一。
 *  互斥锁: 只要被锁住，其他任何线程都不可以访问被保护的资源。如果没有锁，获得资源成功，否则进行阻塞等待资源可用。

3）使用场景：

*  信号量主要适用于进程间通信，当然，也可用于线程间互斥
 *  互斥锁只能用于线程间互斥

> **信号量/互斥体和自旋锁的区别?**  
>   
> 信号量/互斥体允许进程睡眠属于睡眠锁，自旋锁则不允许调用者睡眠，而是让其循环等待（忙等），所以有以下区别应用 :
> 
> 1.  信号量和读写信号量适合于保持时间较长的情况，它们会导致调用者睡眠，因而自旋锁适合于保持时间非常短的情况
> 2.  自旋锁可以用于中断，不能用于进程上下文(会引起死锁)。而信号量不允许使用在中断中，而可以用于进程上下文
> 3.  自旋锁保持期间是抢占失效的，自旋锁被持有时，内核不能被抢占，而信号量和读写信号量保持期间是可以被抢占的
> 
> 另外需要注意的是:
> 
> 1.  信号量锁保护的临界区可包含可能引起阻塞的代码，而自旋锁则绝对要避免用来保护包含这样代码的临界区，因为阻塞意味着要进行进程的切换，如果进程被切换出去后，另一进程企图获取本自旋锁，死锁就会发生。
> 2.  在你占用信号量的同时不能占用自旋锁，因为在你等待信号量时可能会睡眠，而在持有自旋锁时是不允许睡眠的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/4a60f4d5eed14d41b7a9161aad34507f.png
[Link 1]: https://blog.csdn.net/weixin_37650458/article/details/86566693?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.add_param_isCf&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.add_param_isCf