iOS GCD信号量dispatch_semaphore_t

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

---

一、信号量（Semaphore）简介

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

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

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

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

通常来说，信号量有4种操作。

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

---

二、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。

---

三、信号量的应用

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

即使是在多线程并发的场景，也可以通过控制信号量来保证操作的同步。

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

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源码中查看。