通过GCD中的dispatch_barrier_(a)sync加强对sync中所谓等待的理解

首先解释下标题里地括号是什么意思，GCD有个函数叫dispatch_barrier_async，还有个函数叫dispatch_barrier_sync，这个括号只是用来防止标题取得太长…>_<

对于dispatch_barrier_async可能有的朋友没用过，不知道它是干嘛的，简单地介绍一下下，知道的朋友可以跳过此段。 
假设我们原先有6个任务要执行，我们现在要插入一个任务0，这个任务0要在1、2、3都并发执行完了之后才能执行，而4、5、6号任务要在这个任务0结束后才允许并发。大致的意思就跟下面这个图一样 
 
对于这样一种需求，很多朋友的第一反应就是用个group就解决了。确实如此，但是系统提供了一种更加简单地方法，那就是dispatch_barrier_async，我们只要按照前面所述的顺序将任务分配到队列就OK，剩下的都不用管了。dispatch_barrier_async的参数跟dispatch_async一模一样的。

下面开始讲正题 
总结前面所说，dispatch_barrier_async是会等待前面提到的任务0结束的，注意这里是async。说到等待大家必然会想到dispatch_sync，dispatch_sync的任务是串行的，会等待任务结束程序再继续往下走。那dispatch_barrier是否存在一个sync的方法呢？存在……那么问题来了……那dispatch_barrier_async和dispatch_barrier_sync的区别在哪呢？如果没有区别的话苹果何必搞出2个函数呢，区别必然是有的。

先贴上代码，代码非常简单，就是按照之前提的需求写的。 

barrier里给了一个比较费时的操作便于看清楚

给的图里写的是dispatch_barrier_sync，因为我们需要先看看我们熟悉的等待——sync是什么效果，直接跑起来 
 
可以看到，确实是1、2、3号任务并发执行完了，然后再执行的我们的0号任务，再并发执行的4、5、6号任务，当然，point3和barrier之间是有明显停顿的，截图无法表现。对于这个输出，应该是意料之中的。截下来，我们来看看async的效果

代码进行一点点修改，dispatch_barrier_sync改成dispatch_barrier_async。我这里先把aaa、bbb的输出隐藏掉。改完代码可以直接跑起来，我们一起看看结果 
 
好像除了aaa、bbb之外其它的都跟上面sync的情况一模一样（当然，并发的顺序无法控制）,而且point3和barrier之间同样有明显停顿，看来，这个dispatch_barrier_async确实会等待它的任务0执行完。

既然这样那dispatch_barrier_async和dispatch_barrier_sync究竟有什么区别呢？我们把aaa、bbb的输出打开看看就知道了。 
 
区别很明显，跟sync的情况相比，aaa、bbb的输出位置完全不同，async的时候aaa的输出在任务0结束之前，sync的aaa输出在任务0结束之后。

好了，说到这应该差不多能想通了，我们开始总结 
dispatch_barrier_sync和dispatch_barrier_async的共同点： 
1、都会等待在它前面插入队列的任务（1、2、3）先执行完 
2、都会等待他们自己的任务（0）执行完再执行后面的任务（4、5、6）

dispatch_barrier_sync和dispatch_barrier_async的不共同点： 
在将任务插入到queue的时候，dispatch_barrier_sync需要等待自己的任务（0）结束之后才会继续程序，然后插入被写在它后面的任务（4、5、6），然后执行后面的任务 
而dispatch_barrier_async将自己的任务（0）插入到queue之后，不会等待自己的任务结束，它会继续把后面的任务（4、5、6）插入到queue

所以，dispatch_barrier_async的不等待（异步）特性体现在将任务插入队列的过程，它的等待特性体现在任务真正执行的过程。

转自：http://blog.csdn.net/u013046795/article/details/47057585