前言：
在研究《iOS 性能监控（二）—— 主线程卡顿监控》中，
发现有一些GCD信号量的知识之前没有好好梳理过。
故本篇用来梳理一下GCD中信号量dispatch_semaphore_t相关的知识。
一、信号量（Semaphore）简介
信号量（Semaphore）是多线程环境下的一种保护设施，可以用来保证两个或多个关键代码不被并发调用。
在进入一个关键代码段之前，线程必须获取一个信号量。一旦执行完毕，该线程就会释放信号量。等待下一个信号量被发送，线程才能继续获取到新信号量并再次执行关键代码段。
- 要求：线程进入关键代码段前，必须要获取到一个信号量。（发信号
signal与等信号wait应该要一一对应） - 作用：保证关键代码段不被并发调用。
举个例子：
一个停车场，只能容下5辆车。这时候，来了6辆车。只有前5辆能进去。第6辆车等待，当有一辆车离开停车场时，才能进入。
这里，
想进停车场 —— 创建信号，
当前有车位 ，领卡进场 —— 发信号，
当前无车位，排队等卡 —— 等信号，
离开停车场 —— 销毁信号。
通常来说，信号量有4种操作。
- 初始化信号（
initialize/create） - 发信号（
signal/post） - 等信号（
wait/suspend） - 释放信号（
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源码中查看。
