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 举例

• 运行结果如下：

• 在同一个队列里面，栅栏函数前面的任务执行完了，栅栏函数里面的任务可以执行，但是不会堵塞线程。
• 栅栏函数后面的任务还是可以执行的。但是栅栏函数前面的任务，是一定在栅栏函数内部任务之前执行的。

也就是任务 1 和任务 2是必然在栅栏函数前面执行。

• dispatch_barrier_sync：

代码还是👆上面的代码，就是把栅栏函数的异步改成同步了，看看会发生什么样的效果？

• 控制台打印结果如下：

• 栅栏函数前面的任务还是正常执行了，但是后面的任务在栅栏函数的后面执行
• 栅栏函数堵塞了线程，栅栏函数后面的任务在栅栏函数的任务执行完成，才会去执行

还记得上面的一句话吗：栅栏函数只能控制同一并发队列，那么我们试试不是同一个并发队列情况，栅栏函数是否可以拦截住呢？

我们把栅栏函数放在了另一个并发的队列里面，发现并没有拦截住任务的执行，那么是不是异步的原因呢？

那么现在去改成同步看看能不能拦住呢？

从运行的结果来看，发现还是拦不住，说明不是同一个并发的队列，不管栅栏函数是不是同步或者异步，都是拦截不住的，只能是同一个并发队列才可以！

我们再来举个例子🌰，使用全局并发队列看看

从打印结果来看，全局并发队列也是拦不住的，只能是自定义的并发队列才可以，这是为什么呢？去底层源码看看是否可以找到答案！

2. 栅栏函数源码分析

2.1 流程跟踪

上面已经对栅栏函数的作用有一个大致的认识，那么底层的实现逻辑是怎么样的呢？现在就去探索一下。

在源码里面搜索dispatch_barrier_sync，跟流程会走到_dispatch_barrier_sync_f – > _dispatch_barrier_sync_f_inline

这个_dispatch_barrier_sync_f_inline 方法我们之前分析死锁的时候来过这里面，通过符号断点，这里会走_dispatch_sync_f_slow方法，这里设置了DC_FLAG_BARRIER的标签，对栅栏做标记！

这里也是之前同步产生死锁的时候来过的，通过下符号断点继续跟踪流程。

由此跟踪的流程为：_dispatch_sync_f_slow --> _dispatch_sync_invoke_and_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

这里我们之前分析同步和异步的时候也来过这里，这里全局并发的是
_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_drain_non_barriers方法将栅栏之前的任务执行完成。
• 最后会调用_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. 总结

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

更多内容持续更新

🌹 喜欢就点个赞吧👍🌹

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

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