回顾
在上篇博客已经对GCD函数的同步性/异步性还有单例的底层源码，作了详细的分析，那么本篇博客将对栅栏函数，调度组等底层源码进行探索分析！
多线程
iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)
iOS底层探索之多线程(八)—GCD源码分析(函数的同步性、异步性、单例)
1. 栅栏函数基本介绍
1.1 栅栏函数的作用
栅栏函数的作⽤：
最直接的作⽤: 控制任务执⾏顺序，也就是达到同步的效果
-
dispatch_barrier_async：前面的任务执行完毕，才会来到这里 -
dispatch_barrier_sync：作用相同，但是这个会堵塞线程，影响后面的执行
注意：栅栏函数只能控制同一并发队列
1.2 栅栏函数使用举例
-
dispatch_barrier_async举例
dispatch_barrier_async举例
- 运行结果如下：
控制台打印结果
- 在同一个队列里面，
栅栏函数前面的任务执行完了，栅栏函数里面的任务可以执行，但是不会堵塞线程。 - 栅栏函数后面的任务还是可以执行的。但是栅栏函数前面的任务，是一定在栅栏函数内部任务之前执行的。
也就是
任务 1和任务 2是必然在栅栏函数前面执行。
-
dispatch_barrier_sync：
代码还是👆上面的代码，就是把栅栏函数的异步改成同步了，看看会发生什么样的效果？
dispatch_barrier_sync举例
- 控制台打印结果如下：
打印结果
- 栅栏函数前面的任务还是正常执行了，但是后面的任务在栅栏函数的后面执行
- 栅栏函数堵塞了线程，栅栏函数后面的任务在栅栏函数的任务执行完成，才会去执行
还记得上面的一句话吗：
栅栏函数只能控制同一并发队列，那么我们试试不是同一个并发队列情况，栅栏函数是否可以拦截住呢？
不是同一个队列情况举例
我们把
栅栏函数放在了另一个并发的队列里面，发现并没有拦截住任务的执行，那么是不是异步的原因呢？
那么现在去改成同步看看能不能拦住呢？
不是同一个队列情况举例
从运行的结果来看，发现还是拦不住，说明不是同一个并发的队列，不管栅栏函数是不是同步或者异步，都是拦截不住的，只能是同一个并发队列才可以！
我们再来举个例子🌰，使用全局并发队列看看
全局并发队列举例
从打印结果来看，
全局并发队列也是拦不住的，只能是自定义的并发队列才可以，这是为什么呢？去底层源码看看是否可以找到答案！
2. 栅栏函数源码分析
2.1 流程跟踪
上面已经对栅栏函数的作用有一个大致的认识，那么底层的实现逻辑是怎么样的呢？现在就去探索一下。
在源码里面搜索dispatch_barrier_sync，跟流程会走到_dispatch_barrier_sync_f -- > _dispatch_barrier_sync_f_inline
_dispatch_barrier_sync_f_inline
这个
_dispatch_barrier_sync_f_inline 方法我们之前分析死锁的时候来过这里面，通过符号断点，这里会走_dispatch_sync_f_slow方法，这里设置了DC_FLAG_BARRIER的标签，对栅栏做标记！
_dispatch_sync_f_slow
这里也是之前同步产生死锁的时候来过的，通过下符号断点继续跟踪流程。
符号断点跟踪调试
由此跟踪的流程为：
_dispatch_sync_f_slow --> _dispatch_sync_invoke_and_complete_recurse --> _dispatch_sync_complete_recurse，继续在源码里面跟踪发现定位到了这个_dispatch_sync_complete_recurse方法。
_dispatch_sync_complete_recurse
这里是一个
do while循环，判断当前队列里面是否有barrier，有的话就dx_wakeup唤醒执行，直到任务执行完成了，才会执行_dispatch_lane_non_barrier_complete，表示当前队列任务已经执行完成了，并且没有栅栏函数了就会继续往下面的流程走。
#define dx_wakeup(x, y, z) dx_vtable(x)->dq_wakeup(x, y, z)
那么现在去看看dq_wakeup
dq_wakeup
这里我们之前分析同步和异步的时候也来过这里，这里全局并发的是
_dispatch_root_queue_wakeup,串行和并发的是_dispatch_lane_wakeup，那么两者有什么不一样呢？
2.3 自定义的并发队列分析
我们先去看看自定义的并发队列的_dispatch_lane_wakeup
_dispatch_lane_wakeup(dispatch_lane_class_t dqu, dispatch_qos_t qos,
dispatch_wakeup_flags_t flags)
{
dispatch_queue_wakeup_target_t target = DISPATCH_QUEUE_WAKEUP_NONE;
if (unlikely(flags & DISPATCH_WAKEUP_BARRIER_COMPLETE)) {
return _dispatch_lane_barrier_complete(dqu, qos, flags);
}
if (_dispatch_queue_class_probe(dqu)) {
target = DISPATCH_QUEUE_WAKEUP_TARGET;
}
return _dispatch_queue_wakeup(dqu, qos, flags, target);
}
-
判断是否为
barrier形式的，会调用_dispatch_lane_barrier_complete方法处理 -
如果没有
barrier形式的，则走正常的并发队列流程，调用_dispatch_queue_wakeup方法。 -
_dispatch_lane_barrier_complete
_dispatch_lane_barrier_complete
- 如果是串行队列，则会进行等待，等待其他的任务执行完成，再按顺序执行
- 如果是并发队列，则会调用
_dispatch_lane_drain_non_barriers方法将栅栏之前的任务执行完成。 - 最后会调用
_dispatch_lane_class_barrier_complete方法，也就是把栅栏拔掉了，不拦了，从而执行栅栏之后的任务。
_dispatch_lane_class_barrier_complete
2.3 全局并发队列分析
- 全局并发队列，
dx_wakeup对应的是_dispatch_root_queue_wakeup方法，查看源码实现
void
_dispatch_root_queue_wakeup(dispatch_queue_global_t dq,
DISPATCH_UNUSED dispatch_qos_t qos, dispatch_wakeup_flags_t flags)
{
if (!(flags & DISPATCH_WAKEUP_BLOCK_WAIT)) {
DISPATCH_INTERNAL_CRASH(dq->dq_priority,
"Don't try to wake up or override a root queue");
}
if (flags & DISPATCH_WAKEUP_CONSUME_2) {
return _dispatch_release_2_tailcall(dq);
}
}
- 全局并发队列这个里面，并没有对
barrier的判断和处理，就是按照正常的并发队列来处理。 - 全局并发队列为什么没有对栅栏函数进行处理呢？因为全局并发队列除了被我们使用，系统也在使用。
- 如果添加了栅栏函数，会导致队列运行的阻塞，从而影响系统级的运行，所以栅栏函数也就不适用于全局并发队列。
3. 总结
- 使用栅栏函数的时候，要和其他需要执行的任务必须在同一个队列中
- 使用栅栏函数不能使用全局并发队列
- 除了我们使用，系统也在使用。
- 如果添加了栅栏函数，会导致队列运行的阻塞，影响系统级的运行
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得有收获的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹
🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹
网友评论