GCD 被弃方法dispatch_get_current_queue

本文主要是介绍GCD 被弃方法dispatch_get_current_queue，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

想说说被废弃的dispatch_get_current_queue，不得不提一个概念：可重入。

        什么是可重入，来自维基百科：若一个程序或子程序可以“安全的被并行执行(Parallel computing)”，则称其为可重入（reentrant或re-entrant）的。

即当该子程序正在运行时，可以再次进入并执行它（并行执行时，个别的执行结果，都符合设计时的预期）。
     

若一个函数是可重入的，则该函数：

• 不能含有静态（全局）非常量数据
• 不能返回静态（全局）非常量数据的地址
• 只能处理由调用者提供的数据
• 不能依赖于单实例模式资源的锁
• 不能调用(call)不可重入的函数(有呼叫(call)到的函数需满足前述条件)

       有时候我们很希望知道当前执行的queue是谁，比如UI操作需要放在main queue中执行。如果可以知道当前工作的queue是谁，就可以很方便的指定一段代码操作在特定的queue中执行。 dispatch_get_current_queue() 正好能帮上忙。于是乎，在指定的queue中做一些操作，就可以非常清晰的实现：

       

然后潜意识里，觉得这个函数是可重入的。

但当target queue恰好是current queue时，同步阻塞会导致死锁。

问题出在GCD队列本身是不可重入的，串行同步队列的层级关系，是出现问题的根本原因。
为了防止类似的误用，苹果在iOS6废弃了dispatch_get_current_queue()方法。强大的dispatch_get_current_queue()也只能当作一个调试工具了。


那么应该如何保证GCD方法可重入呢？

• dispatch_queue_set_specific 标记队列
• 递归锁

分别给出两种方法的示例代码片段：

1）dispatch_queue_set_specific

2）递归锁

1. void dispatch_reentrant(void (^block)())  
2. {  
3.     static NSRecursiveLock *lock = nil;  
4.     static dispatch_once_t onceToken;  
5.     dispatch_once(&onceToken, ^{  
6.         lock = [[NSRecursiveLock alloc]init];  
7.     });  
8.     [lock lock];  
9.     block();  
10.     [lock unlock];  
11. }  
12.   
13.     dispatch_queue_t queueA = dispatch_queue_create("com.yiyaaixuexi.queueA", NULL);  
14.     dispatch_block_t block = ^{  
15.          //do something  
16.     };  
17.     dispatch_sync(queueA, ^{  
18.         dispatch_reentrant(block);  
19.     });  
    

这篇关于GCD 被弃方法dispatch_get_current_queue的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---