回顾
在上篇博客已经对GCD的sync 同步函数、async 异步函数进行了源码的分析，那么本篇博客继续源码的探索分析！
1. 补充
sync 和 async 的区别
- 是否可以开启新的线程执行任务
- 任务的回调是否具有异步行、同步性
- 是否产生死锁问题
2. 死锁 源码分析
在上篇博客分析，同步 sync函数的流程是_dispatch_sync_f -- > _dispatch_sync_f_inline -- > _dispatch_barrier_sync_f
走到
_dispatch_barrier_sync_f流程中，这与上篇博客的分析是一致的，因为这里dq_width=1，所以是串行队列，如果是并发队列，则会走到_dispatch_sync_f_slow，现在去_dispatch_barrier_sync_f方法里面看看
_dispatch_barrier_sync_f
static void
_dispatch_barrier_sync_f(dispatch_queue_t dq, void *ctxt,
dispatch_function_t func, uintptr_t dc_flags)
{
_dispatch_barrier_sync_f_inline(dq, ctxt, func, dc_flags);
}
这个方法又会调用_dispatch_barrier_sync_f_inline方法
在这个方法里面，会对队列进行判断，是否存在等待或者挂起状态
//判断是否挂起、等待
if (unlikely(!_dispatch_queue_try_acquire_barrier_sync(dl, tid))) {
// 添加任务
return _dispatch_sync_f_slow(dl, ctxt, func, DC_FLAG_BARRIER, dl,
DC_FLAG_BARRIER | dc_flags);
}
在之前的博客里面也提到了死锁相关的内容，出现死锁会报和_dispatch_sync_f_slow相关的错误，如下：
虽然死锁会走_dispatch_sync_f_slow 方法，但是死锁的报错不是_dispatch_sync_f_slow这个报错，而是如下图中所示的0处报错了
真报错的是
__DISPATCH_WAIT_FOR_QUEUE__，那么现在去验证一下
_dispatch_sync_f_slow
在_dispatch_sync_f_slow方法内部，我们发现了刚刚死锁报错的__DISPATCH_WAIT_FOR_QUEUE__，现在去内部看看
__DISPATCH_WAIT_FOR_QUEUE__
在
__DISPATCH_WAIT_FOR_QUEUE__内部，发现了和死锁报错信息基本一样，意思是：
dispatch_sync在当前线程已经拥有的队列上调用 ，对不起兄弟，我已经拥有她了，你来晚一步了
if (unlikely(_dq_state_drain_locked_by(dq_state, dsc->dsc_waiter))) {
DISPATCH_CLIENT_CRASH((uintptr_t)dq_state,
"dispatch_sync called on queue "
"already owned by current thread");
}
这个dsc_waiter是由前面_dispatch_sync_f_slow方法里面传过来来的
_dispatch_tid_self()是线程id，定义如下
_dispatch_thread_port是线程的通道，现在再去看看线程状态的匹配
//状态
uint64_t dq_state = _dispatch_wait_prepare(dq);
if (unlikely(_dq_state_drain_locked_by(dq_state, dsc->dsc_waiter))) {
DISPATCH_CLIENT_CRASH((uintptr_t)dq_state,
"dispatch_sync called on queue "
"already owned by current thread");
}
_dq_state_drain_locked_by
static inline bool
_dq_state_drain_locked_by(uint64_t dq_state, dispatch_tid tid)
{
return _dispatch_lock_is_locked_by((dispatch_lock)dq_state, tid);
}
_dispatch_lock_is_locked_by
static inline bool
_dispatch_lock_is_locked_by(dispatch_lock lock_value, dispatch_tid tid)
{
// equivalent to _dispatch_lock_owner(lock_value) == tid
return ((lock_value ^ tid) & DLOCK_OWNER_MASK) == 0;
}
DLOCK_OWNER_MASK
#define DLOCK_OWNER_MASK ((dispatch_lock)0xfffffffc)
这里就是死锁的判断：异或再作与操作，也就是结果为0就是死锁。翻译一下就是dq_state ^ dsc->dsc_waiter的结果为 0再和DLOCK_OWNER_MASK作与操作等于0。
那么dq_state ^ dsc->dsc_waiter的结果什么情况下会为 0呢？异或是相同为0，因为DLOCK_OWNER_MASK是一个非常大的整数，所以dq_state 和 dsc->dsc_waiter都是为0。
当前队列里面要等待的线程 id和我调用的是一样，我已经处于等待状态，你现在有新的任务过来需要使用我去执行，这样产生了矛盾，进入相互等待状态，进而产生死锁。这就是串行队列执行同步任务产生死锁的原因！
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得有收获的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹
🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹
