前言：

在研讨《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源码中查看。