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

Posted 2021-09-06 卡卡西Sensei

回顾

在上篇博客已经对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和我调用的是一样，我已经处于等待状态，你现在有新的任务过来需要使用我去执行，这样产生了矛盾，进入相互等待状态，进而产生死锁。这就是串行队列执行同步任务产生死锁的原因！

更多内容持续更新

🌹 喜欢就点个赞吧👍🌹

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

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