iOS底层探索之多线程(九)—GCD源码分析(栅栏函数)

回顾

在上篇博客已经对GCD函数的同步性/异步性还有单例的底层源码,作了详细的分析,那么本篇博客将对栅栏函数调度组等底层源码进行探索分析!

多线程

iOS底层探索之多线程(一)—进程和线程

iOS底层探索之多线程(二)—线程和锁

iOS底层探索之多线程(三)—初识GCD

iOS底层探索之多线程(四)—GCD的队列

iOS底层探索之多线程(五)—GCD不同队列源码分析

iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)

iOS底层探索之多线程(七)—GCD源码分析(死锁的原因)

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. 总结

  • 使用栅栏函数的时候,要和其他需要执行的任务必须在同一个队列中
  • 使用栅栏函数不能使用全局并发队列
  • 除了我们使用,系统也在使用。
  • 如果添加了栅栏函数,会导致队列运行的阻塞,影响系统级的运行

更多内容持续更新

喜欢就点个赞吧

觉得有收获的,可以来一波,收藏+关注,评论 + 转发,以免你下次找不到我

欢迎大家留言交流,批评指正,互相学习,提升自我

你可能感兴趣的:(iOS底层探索之多线程(九)—GCD源码分析(栅栏函数))