摘录: 「想名真难」、「猴子的毛」
简化核心函数dispatch_once_f:
void dispatch_once_f(dispatch_once_t *val, void *ctxt, void (*func)(void *)){
volatile long *vval = val;
if (dispatch_atomic_cmpxchg(val, 0l, 1l)) {
func(ctxt); // block真正执行
dispatch_atomic_barrier();
*val = ~0l;
}
else
{
do
{
_dispatch_hardware_pause();
} while (*vval != ~0l);
dispatch_atomic_barrier();
}
}
1、dispatch_atomic_cmpxchg,它是一个宏定义,原型为__sync_bool_compare_and_swap((p), (o), (n)) ,这是LockFree给予CAS的一种原子操作机制,原理就是 如果p==o,那么将p设置为n,然后返回true;否则,不做任何处理返回false
2、在多线程环境中,如果某一个线程A首次进入dispatch_once_f,val==0,这个时候直接将其原子操作设为1,然后执行传入dispatch_once_f的block,然后调用dispatch_atomic_barrier,最后将val的值修改为~0。
3、dispatch_atomic_barrier是一种内存屏障,所谓内存屏障,从处理器角度来说,是用来串行化读写操作的,从软件角度来讲,就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗,处理器不是要乱序执行吗,你插入一个内存屏障,就相当于告诉编译器,屏障前后的指令顺序不能颠倒,告诉处理器,只有等屏障前的指令执行完了,屏障后的指令才能开始执行。所以这里dispatch_atomic_barrier能保证只有在block执行完毕后才能修改*val的值。
4、在首个线程A执行block的过程中,如果其它的线程也进入dispatch_once_f,那么这个时候if的原子判断一定是返回false,于是走到了else分支,于是执行了dowhile循环,其中调用了_dispatch_hardware_pause,这有助于提高性能和节省CPU耗电,pause就像nop,干的事情就是延迟空等的事情。直到首个线程已经将block执行完毕且将*val修改为0,调用dispatch_atomic_barrier后退出。这么看来其它的线程是无法执行block的,这就保证了在dispatch_once_f的block的执行的唯一性,生成的单例也是唯一的。
-
死锁方式1
:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例。
2、上述block()中的某个函数调用了dispatch_sync_safe,同步在T2线程执行代码
3、T2线程正在执行的某个函数需要调用到单例A,将会再次调用dispatch_once。
4、这样T1线程在等block执行完毕,它在等待T2线程执行完毕,而T2线程在等待T1线程的dispatch_once执行完毕,造成了相互等待,故而死锁
-
死锁方式2
:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例;
2、block中可能掉用到了B流程,B流程又调用了C流程,C流程可能调用到了单例A,将会再次调用dispatch_once;
3、这样又造成了相互等待。
dispatch_once也可以通过锁来实现,使用dispatch_semaphore,NSLock,@synchronized 这些都可以实现,但是效率没有dispatch_once高。实测也是可以的。
// 方式1,使用synchronized最简单
+ (instancetype)synchronizedManager {
static Person * m = nil;
@synchronized (self) {
if (m == nil) {
// 模拟耗时操作,给其他线程进入提供机会
sleep(3);
m = [[self alloc] init];
NSLog(@"synchronizedManager 只执行一次是对的");
}
}
return m;
}
// 方式2,使用dispatch_semaphore,需要多一些操作,NSLock同理
static dispatch_semaphore_t sem = nil;
+ (void)initialize {
if (sem == nil) {
sem = dispatch_semaphore_create(1);
}
}
+ (instancetype)semaphoreManager {
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
static Person * m = nil;
if (m == nil) {
// 模拟耗时操作,给其他线程进入提供机会
sleep(3);
m = [[self alloc] init];
NSLog(@"semaphoreManager 只执行一次是对的");
}
dispatch_semaphore_signal(sem);
return m;
}
dispatch_once源码
Apple对于dispatch_once的源码地址
#include "internal.h"
#undef dispatch_once
#undef dispatch_once_f
typedef struct _dispatch_once_waiter_s {
volatile struct _dispatch_once_waiter_s *volatile dow_next;
dispatch_thread_event_s dow_event;
mach_port_t dow_thread;
} *_dispatch_once_waiter_t;
#define DISPATCH_ONCE_DONE ((_dispatch_once_waiter_t)~0l)
#ifdef __BLOCKS__
void
dispatch_once(dispatch_once_t *val, dispatch_block_t block)
{//第一步:我们调用dispatch_once入口,接下来去看最下面dispatch_once_f的定义
dispatch_once_f(val, block, _dispatch_Block_invoke(block));
}
#endif
#if DISPATCH_ONCE_INLINE_FASTPATH
#define DISPATCH_ONCE_SLOW_INLINE inline DISPATCH_ALWAYS_INLINE
#else
#define DISPATCH_ONCE_SLOW_INLINE DISPATCH_NOINLINE
#endif
DISPATCH_ONCE_SLOW_INLINE
static void
dispatch_once_f_slow(dispatch_once_t *val, void *ctxt, dispatch_function_t func)
{
#if DISPATCH_GATE_USE_FOR_DISPATCH_ONCE
dispatch_once_gate_t l = (dispatch_once_gate_t)val;
if (_dispatch_once_gate_tryenter(l)) {
_dispatch_client_callout(ctxt, func);
_dispatch_once_gate_broadcast(l);
} else {
_dispatch_once_gate_wait(l);
}
#else//第三步:主要的流程(为什么走#else请看注解二)
_dispatch_once_waiter_t volatile *vval = (_dispatch_once_waiter_t*)val;
struct _dispatch_once_waiter_s dow = { };
_dispatch_once_waiter_t tail = &dow, next, tmp;
dispatch_thread_event_t event;
//首次更改请求
if (os_atomic_cmpxchg(vval, NULL, tail, acquire)) {
dow.dow_thread = _dispatch_tid_self();
//调用dispatch_once内block回调
_dispatch_client_callout(ctxt, func);
//利用while循环不断处理未完成的更改请求,直到所有更改结束
next = (_dispatch_once_waiter_t)_dispatch_once_xchg_done(val);
while (next != tail) {
tmp = (_dispatch_once_waiter_t)_dispatch_wait_until(next->dow_next);
event = &next->dow_event;
next = tmp;
_dispatch_thread_event_signal(event);
}
} else {//非首次更改请求
_dispatch_thread_event_init(&dow.dow_event);
next = *vval;
for (;;) {
//遍历每一个后续请求,如果状态已经是Done,直接进行下一个,同时该状态检测还用于避免在后续wait之前,信号量已经发出(signal)造成的死锁
if (next == DISPATCH_ONCE_DONE) {
break;
}
//如果当前dispatch_once执行的block没有结束,那么就将这些后续请求添加到链表当中
if (os_atomic_cmpxchgv(vval, next, tail, &next, release)) {
dow.dow_thread = next->dow_thread;
dow.dow_next = next;
if (dow.dow_thread) {
pthread_priority_t pp = _dispatch_get_priority();
_dispatch_thread_override_start(dow.dow_thread, pp, val);
}
_dispatch_thread_event_wait(&dow.dow_event);
if (dow.dow_thread) {
_dispatch_thread_override_end(dow.dow_thread, val);
}
break;
}
}
_dispatch_thread_event_destroy(&dow.dow_event);
}
#endif
}
DISPATCH_NOINLINE
void
dispatch_once_f(dispatch_once_t *val, void *ctxt, dispatch_function_t func)
{
#if !DISPATCH_ONCE_INLINE_FASTPATH
if (likely(os_atomic_load(val, acquire) == DLOCK_ONCE_DONE)) {
return;
}
#endif //第二步:进入dispatch_once_f_slow(这个宏判断请看注解一)
return dispatch_once_f_slow(val, ctxt, func);
}
注解一:
DISPATCH_ONCE_INLINE_FASTPATH
这个宏的值由CPU架构决定,__x86_64__
(64位),__i386__
(32位),__s390x__
(运行在IBM z系统(s390x),可能Apple和IBM比较熟,给他留后门了),以及__APPLE__
这个就无从得知了,可能是Apple自身的平台架构,这些情况下DISPATCH_ONCE_INLINE_FASTPATH = 1
,所以大部分情况也就是1了。
#if defined(__x86_64__) || defined(__i386__) || defined(__s390x__)
#define DISPATCH_ONCE_INLINE_FASTPATH 1
#elif defined(__APPLE__)
#define DISPATCH_ONCE_INLINE_FASTPATH 1
#else
#define DISPATCH_ONCE_INLINE_FASTPATH 0
#endif
注解二:
DISPATCH_GATE_USE_FOR_DISPATCH_ONCE
这个宏的值在lock.h
中有定义:
#pragma mark - gate lock
#if HAVE_UL_UNFAIR_LOCK || HAVE_FUTEX
#define DISPATCH_GATE_USE_FOR_DISPATCH_ONCE 1
#else
#define DISPATCH_GATE_USE_FOR_DISPATCH_ONCE 0
#endif
而HAVE_UL_UNFAIR_LOCK
的值和HAVE_FUTEX
的值也在lock.h
中有定义:
#ifdef __linux__
#define HAVE_FUTEX 1
#else
#define HAVE_FUTEX 0
#endif
#ifdef UL_UNFAIR_LOCK
#define HAVE_UL_UNFAIR_LOCK 1
#endif
从上面的分析可以看出:
1、dispatch_once不止是简单的执行一次,如果再次调用会进入非首次更改的模块,如果有未DONE的请求会被添加到链表中
2、所以dispatch_once本质上可以接受多次请求,会对此维护一个请求链表
3、如果在block执行期间,多次进入调用同类的dispatch_once函数(即单例函数),会导致整体链表无限增长,造成永久性死锁
4、对于开始问题大致上和 A -> B -> A的流程类似,理解dispatch_once的内部流程有利于在使用中规避隐藏的问题。