线程锁-dispatch_semaphore

GCD信号量

信号量的概念

如何在GCD中快速的控制并发呢？
答案就是dispatch_semaphore
　　信号量是一个整形值并且具有一个初始计数值，并且支持两个操作：信号通知和等待。当一个信号量被信号通知，其计数会被增加。当一个线程在一个信号量上等待时，线程会被阻塞（如果有必要的话），直至计数器大于零，然后线程会减少这个计数。
　　在GCD中有三个函数是semaphore的操作，分别是：

dispatch_semaphore_create　　　创建一个semaphore
dispatch_semaphore_signal　　　发送一个信号
dispatch_semaphore_wait　　　　等待信号

　　简单的介绍一下这三个函数，第一个函数有一个整形的参数，我们可以理解为信号的总量，
dispatch_semaphore_signal是发送一个信号，自然会让信号总量加1，
dispatch_semaphore_wait等待信号,当信号总量少于0的时候就会一直等待，否则就可以正常的执行，并让信号总量-1，
根据这样的原理，我们便可以快速的创建一个并发控制来同步任务和有限资源访问控制。

代码讲解

- (void)viewWillAppear:(BOOL)animated {
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSLog(@"信号已发送");
        dispatch_semaphore_signal(semaphore);
        for (int i = 0; i < 10; i++) {
            NSLog(@"%i", i);
        }
    });
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        NSLog(@"信号已接受");
        for (int i = 0; i < 10; i++) {
            NSLog(@"第二个block%i", i);
        }
    });
}

为了确保 信号先发送再接受,
就可以使用信号量创建的时候为0, 表示当前的资源不可使用,
当并发执行第二个block的时候发现需要等待信号量为1. 所以暂时线程不执行
而第一个block是不需要等待信号的.于是先执行第一个block,并且发送一个信号.于是第二个等待执行的block会执行.
此时因为当前第一个block尚未执行完毕,那么此时两个block将会交替执行
换句话说: 如果block发送信号注释掉不执行 dispatch_semaphore_signal(semaphore);那么block2就不会打印信号已接受就没有下文了

2016-11-05 16:41:34.529 Multithreading[15864:468169] 信号已发送
2016-11-05 16:41:34.529 Multithreading[15864:468185] 信号已接受
2016-11-05 16:41:34.529 Multithreading[15864:468169] 0
2016-11-05 16:41:34.529 Multithreading[15864:468185] 第二个block0
2016-11-05 16:41:34.529 Multithreading[15864:468185] 第二个block1
2016-11-05 16:41:34.529 Multithreading[15864:468169] 1
2016-11-05 16:41:34.529 Multithreading[15864:468185] 第二个block2
2016-11-05 16:41:34.530 Multithreading[15864:468169] 2
2016-11-05 16:41:34.530 Multithreading[15864:468185] 第二个block3
2016-11-05 16:41:34.530 Multithreading[15864:468169] 3
2016-11-05 16:41:34.530 Multithreading[15864:468185] 第二个block4
2016-11-05 16:41:34.530 Multithreading[15864:468169] 4