iOS GCD信号量dispatch_semaphore_t

前言：
在研究《iOS 性能监控（二）—— 主线程卡顿监控》中，
发现有一些GCD信号量的知识以前没有好好梳理过。
故本篇用来梳理一下GCD中信号量dispatch_semaphore_t相关的知识。

---

1、信号量（Semaphore）简介

信号量（Semaphore）是多线程环境下的一种保护设施，能够用来保证两个或多个关键代码不被并发调用。

在进入一个关键代码段以前，线程必须获取一个信号量。一旦执行完毕，该线程就会释放信号量。等待下一个信号量被发送，线程才能继续获取到新信号量并再次执行关键代码段。

• 要求：线程进入关键代码段前，必需要获取到一个信号量。（发信号signal与等信号wait应该要一一对应）
• 做用：保证关键代码段不被并发调用。

举个例子：
一个停车场，只能容下5辆车。这时候，来了6辆车。只有前5辆能进去。第6辆车等待，当有一辆车离开停车场时，才能进入。
这里，
想进停车场 —— 建立信号，
当前有车位 ，领卡进场 —— 发信号，
当前无车位，排队等卡 —— 等信号，
离开停车场 —— 销毁信号。

一般来讲，信号量有4种操做。

1. 初始化信号（initialize/create）
2. 发信号（signal/post）
3. 等信号（wait/suspend）
4. 释放信号（destroy）

---

2、GCD信号量（dispatch_semphore_t）

而在咱们iOS开发中，想使用信号量，首先想到的就是GCD中的dispatch_semphore_t。

1. 建立信号量

• 方法：dispatch_semaphore_create(long value)

dispatch_semaphore_create(long value); //!< 建立信号量
复制代码

• 说明：

参数	说明
value	信号量的初始数量（>=0）。 注意：传递一个小于零的值将会返回NULL。

若是 value > 0，就至关于建立了个信号量，并同时发出value个信号。
若是 value = 0，就至关于单纯仅仅建立了个信号量，还没发信号。
若是 value < 0，直接failure，返回一个NULL。

2. 发送信号量

• 方法：dispatch_semaphore_signal(dispatch_semaphore_t dsema);

dispatch_semaphore_signal(dispatch_semaphore_t dsema); //!< 发送信号量
复制代码

• 说明：

参数	说明
dispatch_semaphore_t	传入所要发送信号的信号量。 dispatch_semaphore_t的信号计数+1。

3. 等待信号量

• 方法：dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);

dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout); //!< 等待信号量
复制代码

• 说明：

参数	说明
dispatch_semaphore_t	传入所要等待信号的信号量。 dispatch_semaphore_t的信号计数-1。
dispatch_time_t	超时等待时间。超过该时间就返回非0，并会直接往下执行。 也能够设置为DISPATCH_TIME_FOREVER，永久等待。

返回值	说明
Int	成功收到信号返回0，超时未收到返回非0。

---

3、信号量的应用

使用信号量使“异步”线程完成“同步”操做。

即便是在多线程并发的场景，也能够经过控制信号量来保证操做的同步。

举个例子：一般，咱们要实现异步线程完成同步操做。有两种作法：

1. 第一种：使用串行队列+异步操做。

这种状况只会开启一条子线程，并按顺序执行串行操做。

dispatch_queue_t queue = dispatch_queue_create("serial", DISPATCH_QUEUE_SERIAL);
    dispatch_async(queue, ^{
        NSLog(@"111:%@",[NSThread currentThread]);
    });
    dispatch_async(queue, ^{
        NSLog(@"222:%@",[NSThread currentThread]);
    });
    dispatch_async(queue, ^{
        NSLog(@"333:%@",[NSThread currentThread]);
    });
复制代码

这种方式有些缺陷：

第一： 由于是异步操做，因此会开启一个新的子线程， 同时又是串行队列，因此只会开启一条子线程进行同步操做。 丧失了多线程的优点。

第二： 须要写在一个方法里去作， 而实际开发中，可能异步分布在各个方法中，但同时又想串行去执行。

2. 第二种：使用信号量，控制多线程下的同步操做。

dispatch_semaphore_t sem = dispatch_semaphore_create(0);
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        
        NSLog(@"任务1:%@",[NSThread currentThread]);
        dispatch_semaphore_signal(sem);
    });
    
    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
    
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSLog(@"任务2:%@",[NSThread currentThread]);
        dispatch_semaphore_signal(sem);
    });
    
    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
    
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSLog(@"任务3:%@",[NSThread currentThread]);
    });
复制代码

固然，这里只是个例子。在实际应用中， 发送信号（signal），与等待信号（wait）每每是成对出现的。 同时，一般是分开在不一样的方法里调用。

例如，在《iOS 性能监控（二）—— 主线程卡顿监控》当中：
监控主线程的CommonModes发生变化时，会发送信号。
同时会开启一条子线程的loop持续监听CommonModes的变化，等待信号。
在某些条件下，超时等待时，就说明主线程当前处于卡顿状态。
保存当前的主线程方法调用堆栈就达到了监控的目的。

PS：详细的实现，可在QiLagMonitor源码中查看。