转载至:https://blog.csdn.net/u013046795/article/details/47057585
首先解释下标题里地括号是什么意思,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的不等待(异步)特性体现在将任务插入队列的过程,它的等待特性体现在任务真正执行的过程。