从一次翻车现场到GCD的源码分析
一切都起源于一次Fabric上的crash分析。node
Crash Log
Fabric上忽然出现一些下载业务使用GCD group引起的crash，以下：ios
#0. Crashed: com.apple.main-thread
0 libdispatch.dylib 0x192759b3c dispatch_group_leave.cold.1 + 36
1 libdispatch.dylib 0x19272ad84 _dispatch_group_wake + 114
2 MTXX 0x103be1af8 __38-[xxxxxx downloadCompletion]_block_invoke + 108 (xxxxxx.m:108)
3 libdispatch.dylib 0x192728b7c _dispatch_call_block_and_release + 32
4 libdispatch.dylib 0x192729fd8 _dispatch_client_callout + 20
5 libdispatch.dylib 0x192735cc8 _dispatch_main_queue_callback_4CF + 968
6 CoreFoundation 0x1929ffcc8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
7 CoreFoundation 0x1929faa24 __CFRunLoopRun + 1980
8 CoreFoundation 0x1929f9f40 CFRunLoopRunSpecific + 480
9 GraphicsServices 0x19cc8a534 GSEventRunModal + 108
10 UIKitCore 0x196b85580 UIApplicationMain + 1940
11 MTXX 0x105c6af10 main + 16 (main.m:16)
12 libdyld.dylib 0x192878e18 start + 4
复制代码
凭借之前的经验，这显然是GCD group的enter/leave没有匹配引起的问题。dispatch_group_enter函数已经明确说了要跟dispatch_group_leave成对使用。git
/*! * @function dispatch_group_enter * * @abstract * Manually indicate a block has entered the group * * @discussion * Calling this function indicates another block has joined the group through * a means other than dispatch_group_async(). Calls to this function must be * balanced with dispatch_group_leave(). * * @param group * The dispatch group to update. * The result of passing NULL in this parameter is undefined. */
API_AVAILABLE(macos(10.6), ios(4.0))
DISPATCH_EXPORT DISPATCH_NONNULL_ALL DISPATCH_NOTHROW void dispatch_group_enter(dispatch_group_t group);
复制代码
第一次分析
那么，通过仔细的review，发现确实有一处漏洞可能致使dispatch_group_leave不执行。代码逻辑大概以下，仅列出了本文可能相关的部分伪代码：github
- (void)downloadURLs:(NSURL *)urls finishCompletion:(void(^)(NSURL *URL))finishCompletion {
dispatch_group_t dispatchGroup = dispatch_group_create();
for (NSURL *url in urls) {
dispatch_group_enter(dispatchGroup);
[self downloadURL:url finishCompletion:^(NSURL *url, BOOL isSuccess) {
// 下载成功与否的逻辑代码
// xxxxx
dispatch_group_leave(dispatchGroup);
}];
}
dispatch_group_notify(dispatchGroup, dispatch_get_main_queue(), ^{
if (finishCompletion) {
finishCompletion();
}
});
}
- (void)downloadURL:(NSURL *)url finishCompletion:(void(^)(NSURL *URL, BOOL isSuccess))finishCompletion {
// 各类逻辑，if-else判断等。。。项目代码比较久了的缘由。
// 其中有一个暂停任务的判断，大概代码以下：
DownloadItem *downloadItem = [self downloadItemForURL:url];
if (downloadItem正在暂停) {
// 继续下载操做
return;
}
// xxxxxx
// 触发实际的下载操做
}
复制代码
注意，由于代码比较久的缘由，执行继续下载操做的时候，并未将finishCompletion传递，所以finishCompletion也就没有机会执行了。因此致使group的enter/leave不匹配，修改代码以下：macos
if (downloadItem正在暂停) {
// 继续下载操做
downloadItem.finishCompletion = finishCompletion;
return;
}
复制代码
一番探索
改了以后，内心却依然感受不太踏实，果然就是这样修改的么？bash
仔细思考这一番解释：多线程
dispatch_group_enter: Calling this function indicates another block has joined the group through a means other than dispatch_group_async(). Calls to this function must be balanced with dispatch_group_leave().app
也没说缺乏dispatch_group_leave就会致使崩溃？那就用代码来试一试：less
试验代码
缺乏dispatch_group_leave
- (void)group_leave_not_crash_1 {
dispatch_group_t group = dispatch_group_create();
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 1");
});
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 2");
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"dispatch_group_notify");
});
NSLog(@"done");
}
复制代码
输出：async
done
global_queue block 1
global_queue block 2
复制代码
并未发生崩溃。啪啪打脸的声音却是有的。
缺乏dispatch_group_enter
- (void)group_leave_crash {
dispatch_group_t group = dispatch_group_create();
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"dispatch_group_notify main_queue block 1");
dispatch_group_leave(group);
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"dispatch_group_notify main_queue block 2");
dispatch_group_leave(group);
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"dispatch_group_notify");
});
NSLog(@"done");
}
复制代码
两句过分调用dispatch_group_leave的地方都会致使崩溃。
dispatch_group_enter与dispatch_group_leave不严格匹配
- (void)group_leave_not_crash_2 {
dispatch_group_t group = dispatch_group_create();
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 1");
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 2");
dispatch_group_leave(group);
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"dispatch_group_notify");
});
NSLog(@"done");
}
- (void)group_leave_not_crash_3 {
dispatch_group_t group = dispatch_group_create();
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 1");
dispatch_group_leave(group);
});
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"global_queue block 2");
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"dispatch_group_notify");
});
NSLog(@"done");
}
复制代码
输出结果都是：
done
global_queue block 1
global_queue block 2
dispatch_group_notify
复制代码
dispatch_group_enter与dispatch_group_leave并未严格地一一对应，但dispatch_group_notify的那个notification block成功执行了。这个有点奇怪。。。
结论
- 仅有dispatch_group_enter，缺乏dispatch_group_leave，不会有问题
- 缺乏dispatch_group_enter，执行dispatch_group_leave，直接致使崩溃
- dispatch_group_enter与dispatch_group_leave不严格匹配，可是个数匹配，不会有问题
libdispatch的源码解析
分析崩溃堆栈
缺乏dispatch_group_enter的那个demo，是在dispatch_group_leave(group);那一行直接致使的崩溃：Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)。若是打印group对象，为 <OS_dispatch_group: group[0x600001088190] = { xref = 1, ref = 1, count = 1073741823, gen = 0, waiters = 0, notifs = 0 }> 。
看一看调用堆栈：
0x108e8fb30 <+0>: pushq %rbp
0x108e8fb31 <+1>: movq %rsp, %rbp
0x108e8fb34 <+4>: subq $0x20, %rsp
0x108e8fb38 <+8>: movq %rdi, -0x8(%rbp)
0x108e8fb3c <+12>: movq %rsi, -0x10(%rbp)
0x108e8fb40 <+16>: callq 0x108e900a8 ; symbol stub for: dispatch_group_create
0x108e8fb45 <+21>: movq %rax, -0x18(%rbp)
0x108e8fb49 <+25>: movq -0x18(%rbp), %rdi
0x108e8fb4d <+29>: callq 0x108e900b4 ; symbol stub for: dispatch_group_leave
-> 0x108e8fb52 <+34>: xorl %ecx, %ecx
0x108e8fb54 <+36>: movl %ecx, %esi
0x108e8fb56 <+38>: leaq -0x18(%rbp), %rax
0x108e8fb5a <+42>: movq %rax, %rdi
0x108e8fb5d <+45>: callq 0x108e900f6 ; symbol stub for: objc_storeStrong
0x108e8fb62 <+50>: addq $0x20, %rsp
0x108e8fb66 <+54>: popq %rbp
0x108e8fb67 <+55>: retq
复制代码
libdispatch.dylib`dispatch_group_leave:
0x10f528955 <+0>: movl $0x4, %eax
0x10f52895a <+5>: lock
0x10f52895b <+6>: xaddq %rax, 0x30(%rdi)
0x10f528960 <+11>: cmpl $-0x4, %eax
0x10f528963 <+14>: jae 0x10f52896d ; <+24>
0x10f528965 <+16>: andl $-0x4, %eax
0x10f528968 <+19>: testl %eax, %eax
0x10f52896a <+21>: je 0x10f5289a3 ; <+78>
0x10f52896c <+23>: retq
0x10f52896d <+24>: addq $0x4, %rax
0x10f528971 <+28>: movq %rax, %rsi
0x10f528974 <+31>: movq %rax, %rcx
0x10f528977 <+34>: andq $-0x4, %rcx
0x10f52897b <+38>: testl $0xfffffffc, %esi ; imm = 0xFFFFFFFC
0x10f528981 <+44>: cmovneq %rax, %rcx
0x10f528985 <+48>: andq $-0x3, %rcx
0x10f528989 <+52>: cmpq %rcx, %rax
0x10f52898c <+55>: je 0x10f528999 ; <+68>
0x10f52898e <+57>: movq %rsi, %rax
0x10f528991 <+60>: lock
0x10f528992 <+61>: cmpxchgq %rcx, 0x30(%rdi)
0x10f528997 <+66>: jne 0x10f528971 ; <+28>
0x10f528999 <+68>: movl $0x1, %edx
0x10f52899e <+73>: jmp 0x10f5289af ; _dispatch_group_wake
0x10f5289a3 <+78>: pushq %rbp
0x10f5289a4 <+79>: movq %rsp, %rbp
0x10f5289a7 <+82>: movq %rax, %rdi
0x10f5289aa <+85>: callq 0x10f55a66d ; dispatch_group_leave.cold.1
复制代码
libdispatch.dylib`dispatch_group_leave.cold.1:
0x10f55a66d <+0>: movq %rdi, %rax
0x10f55a670 <+3>: leaq 0x5bd6(%rip), %rcx ; "BUG IN CLIENT OF LIBDISPATCH: Unbalanced call to dispatch_group_leave()"
0x10f55a677 <+10>: movq %rcx, 0x27ad2(%rip) ; gCRAnnotations + 8
0x10f55a67e <+17>: movq %rax, 0x27afb(%rip) ; gCRAnnotations + 56
-> 0x10f55a685 <+24>: ud2
复制代码
崩溃的关键信息以下，也指明了确实是引起了Unbalanced call，并且跟Fabric上的crash log一致。
Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
dispatch_group_leave(group);
callq 0x10f55a66d ; dispatch_group_leave.cold.1
"BUG IN CLIENT OF LIBDISPATCH: Unbalanced call to dispatch_group_leave()"
复制代码
所以，能够肯定该crash也一样是过分调用了dispatch_group_leave函数致使的，因此第一次的修改果真是错误的。
过分调用dispatch_group_leave确实会崩溃，但具体缘由是什么？想弄懂以上的这些，只能去研究GCD的源码了。
dispatch_group_leave
dispatch_group_leave的源码以下：
void dispatch_group_leave(dispatch_group_t dg) {
// The value is incremented on a 64bits wide atomic so that the carry for
// the -1 -> 0 transition increments the generation atomically.
uint64_t new_state, old_state = os_atomic_add_orig2o(dg, dg_state,
DISPATCH_GROUP_VALUE_INTERVAL, release);
uint32_t old_value = (uint32_t)(old_state & DISPATCH_GROUP_VALUE_MASK);
if (unlikely(old_value == DISPATCH_GROUP_VALUE_1)) {
old_state += DISPATCH_GROUP_VALUE_INTERVAL;
do {
new_state = old_state;
if ((old_state & DISPATCH_GROUP_VALUE_MASK) == 0) {
new_state &= ~DISPATCH_GROUP_HAS_WAITERS;
new_state &= ~DISPATCH_GROUP_HAS_NOTIFS;
} else {
// If the group was entered again since the atomic_add above,
// we can't clear the waiters bit anymore as we don't know for
// which generation the waiters are for
new_state &= ~DISPATCH_GROUP_HAS_NOTIFS;
}
if (old_state == new_state) break;
} while (unlikely(!os_atomic_cmpxchgv2o(dg, dg_state,
old_state, new_state, &old_state, relaxed)));
return _dispatch_group_wake(dg, old_state, true);
}
if (unlikely(old_value == 0)) {
DISPATCH_CLIENT_CRASH((uintptr_t)old_value,
"Unbalanced call to dispatch_group_leave()");
}
}
复制代码
Unbalanced call出现的时机，就是old_value为0的时候。os_atomic_add_orig2o操做是一个加操做，即往dispatch_group_t对象中的某个字段dg_bits加一个值DISPATCH_GROUP_VALUE_INTERVAL，而加以前的旧值就是old_value。
因此，当old_value已经为0的时候，再执行dispatch_group_leave调用，就会触发Unbalanced call的崩溃。
dispatch_group_enter
那只有一个dispatch_group_enter，而没有对应的leave是不会崩溃的。若是是由于dispatch_group_enter的Unbalanced call，会出现什么状况呢？
void dispatch_group_enter(dispatch_group_t dg) {
// The value is decremented on a 32bits wide atomic so that the carry
// for the 0 -> -1 transition is not propagated to the upper 32bits.
uint32_t old_bits = os_atomic_sub_orig2o(dg, dg_bits,
DISPATCH_GROUP_VALUE_INTERVAL, acquire);
uint32_t old_value = old_bits & DISPATCH_GROUP_VALUE_MASK;
if (unlikely(old_value == 0)) {
_dispatch_retain(dg); // <rdar://problem/22318411>
}
if (unlikely(old_value == DISPATCH_GROUP_VALUE_MAX)) {
DISPATCH_CLIENT_CRASH(old_bits,
"Too many nested calls to dispatch_group_enter()");
}
}
复制代码
这个enter就很好理解了。os_atomic_sub_orig2o操做是一个减操做，即往dispatch_group_t对象中的某个字段dg_bits减一个值DISPATCH_GROUP_VALUE_INTERVAL，而减以前的旧值就是old_value。当old_value为DISPATCH_GROUP_VALUE_MAX的时候，再执行dispatch_group_enter调用，就会触发Unbalanced call的崩溃。
测试一下：
- (void)group_enter_crash_1 {
dispatch_group_t group = dispatch_group_create();
while (YES) {
dispatch_group_enter(group); // 要挺久的，直接触发dispatch_group_enter.cold.2
// <OS_dispatch_group: group[0x600003c73a70] = { xref = 1, ref = 2, count = 0, gen = 0, waiters = 0, notifs = 0 }>
}
}
复制代码
确实发生了崩溃，不过须要几秒钟，要使得os_atomic_sub_orig2o操做发生至关多的数量，才能使得old_value为DISPATCH_GROUP_VALUE_MAX的条件发生。此时的关键堆栈信息为：
Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
dispatch_group_enter
callq 0x10e155687 ; dispatch_group_enter.cold.1
movl %eax, %edi
callq 0x10e155697 ; dispatch_group_enter.cold.2
"BUG IN CLIENT OF LIBDISPATCH: Too many nested calls to dispatch_group_enter()"
复制代码
所以，GCD的group enter/leave操做，就是会对一个字段值执行加/减操做，而避免Unbalanced call的方式就是成对出现。这也解释了dispatch_group_enter与dispatch_group_leave不严格匹配的时候，不会致使崩溃的缘由。
dispatch_group_create
dispatch_group_create的源码以下，显然就只是一个初始化操做，而后给对应的group enter/leave须要的字段值赋一个初始值，这里应该是0。
DISPATCH_ALWAYS_INLINE
static inline dispatch_group_t
_dispatch_group_create_with_count(uint32_t n)
{
dispatch_group_t dg = _dispatch_object_alloc(DISPATCH_VTABLE(group),
sizeof(struct dispatch_group_s));
dg->do_next = DISPATCH_OBJECT_LISTLESS;
dg->do_targetq = _dispatch_get_default_queue(false);
if (n) {
os_atomic_store2o(dg, dg_bits,
-n * DISPATCH_GROUP_VALUE_INTERVAL, relaxed);
os_atomic_store2o(dg, do_ref_cnt, 1, relaxed); // <rdar://22318411>
}
return dg;
}
dispatch_group_t
dispatch_group_create(void)
{
return _dispatch_group_create_with_count(0);
}
复制代码
dispatch group enter/leave的原理
到这里，已经基本明确了dispatch_group_enter和dispatch_group_leave的原理。dispatch_group_enter将dispatch_group_t对象中的某个字段dg_bits的值执行减操做（减一），而dispatch_group_leave将其执行加操做（加一）。当dispatch_group_leave执行的时候，必定要确保以前调用过dispatch_group_enter（该字段值小于一），这也就是balanced call的意思。
第二次分析
有了以上的分析，已经能够明确第一次的分析是错误的。
再看一下downloadURL的实际操做中finishCompletion的调用时机：
- (void)downloadURL:(NSURL *)url finishCompletion:(void(^)(NSURL *URL, BOOL isSuccess))finishCompletion {
// 各类逻辑，if-else判断等。。。项目代码比较久了的缘由。
if (根据url和downloadItems断定，是否正在下载中) {
// 相应操做
return;
}
// 其中有一个暂停任务的判断，大概代码以下：
DownloadItem *downloadItem = [self downloadItemForURL:url];
if (downloadItem正在暂停) {
// 继续下载操做
return;
}
// xxxxxx
// 触发实际的下载操做
// 1. 使用url构建一个NSURLRequest，再构建一个AFDownloadRequestOperation
// 2. 根据url构建一个downloadItem对象，传入下载完成回调finishCompletion，装入downloadItems字典中。
// 3. 设置CompletionBlock，其中根据url来获取downloadItem，根据条件来执行其finishCompletion
// 4. 添加到queue中，发起下载请求
[task setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
DownloadItem *downloadItem = [self getDownloadItem:operation.request.URL];
// 根据下载状态，执行downloadItem中的finishCompletion
}];
}
复制代码
代码中使用downloadItems字典来存储下载封装对象downloadItem，finishCompletion即为外部传入的下载完成回调。。
self.downloadItems[url] = downloadItem;
- (DownloadItem *)getDownloadItem:(NSURL *)url
{
return self.downloadItems[url.absoluteString];
}
复制代码
虽然代码比较久了，但流程看起来好像没啥问题。。。然而仔细一想，涉及到downloadItems字典的逻辑貌似最容易埋坑，思考一番果真恍然大悟。
问题确实就出在downloadItems字典这一块：
- 假设传入URL，构建downloadItem A对象，传入finishCompletion A，存入downloadItems字典中。根据URL发起下载操做 A。这一步流程正常。
- 再次下载一样一个连接URL，正常不会有问题，那万一出现多线程场景呢？代码对downloadItems字典的相关操做没有作线程保护。
- 假设多线程场景下：使用同一个URL，可能同时符合过滤条件，而触发实际的下载操做。即，构建downloadItem B对象，传入finishCompletion B，存入downloadItems字典中。根据URL发起下载操做 B。
- 此时downloadItems字典中，URL对应的downloadItem从以前的downloadItem A，变成了downloadItem B。
- 两个下载操做都完成后，根据URL取出downloadItem，此时只能取到downloadItem B，执行finishCompletion B，里边包含一个dispatch_group_leave操做。所以下载操做 A和下载操做 B都会触发finishCompletion B。致使B相关流程，出现dispatch_group_leave的Unbalanced call，致使崩溃。
知道了根本缘由就好办了，改动其实也很简单，在下载任务task完成的回调setCompletionBlockWithSuccess中，不要从downloadItems字典中取出downloadItem。而是经过捕获当前的局部变量downloadItem便可获取到正确的downloadItem。
总结
iOS相关的官方文档，大部分都写得很是好。可是也有个别一些，如GCD group，写得太简略，让人很容易似懂非懂。这个时候，就是须要show me the code的时候了。
One More Thing
知道了GCD group enter/leave的原理，相信之后便不会再犯相似的错误了。最后，还有一个疑问，dispatch_group_notify里边的notification block究竟是如何触发执行的呢？
dispatch_group_t
关于dispatch_group_t这个结构体，以前一直没有分析。
typedef struct dispatch_group_s *dispatch_group_t;
struct dispatch_group_s {
DISPATCH_OBJECT_HEADER(group);
DISPATCH_UNION_LE(uint64_t volatile dg_state,
uint32_t dg_bits,
uint32_t dg_gen
) DISPATCH_ATOMIC64_ALIGN;
struct dispatch_continuation_s *volatile dg_notify_head;
struct dispatch_continuation_s *volatile dg_notify_tail;
};
复制代码
dg_bits是enter/leave须要的字段值，而该值在其余GCD接口中也须要使用。两个dispatch_continuation_t对象，dg_notify_head和dg_notify_tail则是group notification block相关的结构了，能够看出封装notification block的结构是以链表形式保存的group中的。
typedef struct dispatch_continuation_s {
DISPATCH_CONTINUATION_HEADER(continuation);
} *dispatch_continuation_t;
// If dc_flags is less than 0x1000, then the object is a continuation.
// Otherwise, the object has a private layout and memory management rules. The
// layout until after 'do_next' must align with normal objects.
#define DISPATCH_CONTINUATION_HEADER(x) \ union { \ const void *do_vtable; \ uintptr_t dc_flags; \ }; \ union { \ pthread_priority_t dc_priority; \ int dc_cache_cnt; \ uintptr_t dc_pad; \ }; \ struct voucher_s *dc_voucher; \ struct dispatch_##x##_s *volatile do_next; \ dispatch_function_t dc_func; \ void *dc_ctxt; \ void *dc_data; \ void *dc_other
复制代码
dispatch_continuation_t结构体的内容其实很少，不过没啥注释，基本看不出来啥。
dispatch_group_notify
看一下dispatch_group_notify的源码：
DISPATCH_ALWAYS_INLINE
static inline void
_dispatch_group_notify(dispatch_group_t dg, dispatch_queue_t dq,
dispatch_continuation_t dsn)
{
uint64_t old_state, new_state;
dispatch_continuation_t prev;
dsn->dc_data = dq;
_dispatch_retain(dq);
prev = os_mpsc_push_update_tail(os_mpsc(dg, dg_notify), dsn, do_next);
if (os_mpsc_push_was_empty(prev)) _dispatch_retain(dg);
os_mpsc_push_update_prev(os_mpsc(dg, dg_notify), prev, dsn, do_next);
if (os_mpsc_push_was_empty(prev)) {
os_atomic_rmw_loop2o(dg, dg_state, old_state, new_state, release, {
new_state = old_state | DISPATCH_GROUP_HAS_NOTIFS;
if ((uint32_t)old_state == 0) {
os_atomic_rmw_loop_give_up({
return _dispatch_group_wake(dg, new_state, false);
});
}
});
}
}
DISPATCH_NOINLINE void dispatch_group_notify_f(dispatch_group_t dg, dispatch_queue_t dq, void *ctxt, dispatch_function_t func) {
dispatch_continuation_t dsn = _dispatch_continuation_alloc();
_dispatch_continuation_init_f(dsn, dq, ctxt, func, 0, DC_FLAG_CONSUME);
_dispatch_group_notify(dg, dq, dsn);
}
#ifdef __BLOCKS__
void dispatch_group_notify(dispatch_group_t dg, dispatch_queue_t dq, dispatch_block_t db) {
dispatch_continuation_t dsn = _dispatch_continuation_alloc();
_dispatch_continuation_init(dsn, dq, db, 0, DC_FLAG_CONSUME);
_dispatch_group_notify(dg, dq, dsn);
}
#endif
复制代码
notification block的执行，显然是_dispatch_group_wake调用触发的。若dispatch_group_notify函数调用以前，并未有执行过dispatch_group_enter，则会直接触发_dispatch_group_wake。
dispatch_group_notify函数会使用_dispatch_continuation_init函数，将一个dispatch_block_t对象db存入dispatch_group_t对象dg中。
_dispatch_continuation_init
_dispatch_continuation_init函数中则是对dispatch_continuation_t对象的各类初始化操做。
DISPATCH_ALWAYS_INLINE
static inline dispatch_qos_t
_dispatch_continuation_init_f(dispatch_continuation_t dc,
dispatch_queue_class_t dqu, void *ctxt, dispatch_function_t f,
dispatch_block_flags_t flags, uintptr_t dc_flags)
{
pthread_priority_t pp = 0;
dc->dc_flags = dc_flags | DC_FLAG_ALLOCATED;
dc->dc_func = f;
dc->dc_ctxt = ctxt;
// in this context DISPATCH_BLOCK_HAS_PRIORITY means that the priority
// should not be propagated, only taken from the handler if it has one
if (!(flags & DISPATCH_BLOCK_HAS_PRIORITY)) {
pp = _dispatch_priority_propagate();
}
_dispatch_continuation_voucher_set(dc, flags);
return _dispatch_continuation_priority_set(dc, dqu, pp, flags);
}
DISPATCH_ALWAYS_INLINE
static inline dispatch_qos_t
_dispatch_continuation_init(dispatch_continuation_t dc,
dispatch_queue_class_t dqu, dispatch_block_t work,
dispatch_block_flags_t flags, uintptr_t dc_flags)
{
void *ctxt = _dispatch_Block_copy(work);
dc_flags |= DC_FLAG_BLOCK | DC_FLAG_ALLOCATED;
if (unlikely(_dispatch_block_has_private_data(work))) {
dc->dc_flags = dc_flags;
dc->dc_ctxt = ctxt;
// will initialize all fields but requires dc_flags & dc_ctxt to be set
return _dispatch_continuation_init_slow(dc, dqu, flags);
}
dispatch_function_t func = _dispatch_Block_invoke(work);
if (dc_flags & DC_FLAG_CONSUME) {
func = _dispatch_call_block_and_release;
}
return _dispatch_continuation_init_f(dc, dqu, ctxt, func, flags, dc_flags);
}
DISPATCH_ALWAYS_INLINE
static inline dispatch_qos_t
_dispatch_continuation_priority_set(dispatch_continuation_t dc,
dispatch_queue_class_t dqu,
pthread_priority_t pp, dispatch_block_flags_t flags)
{
dispatch_qos_t qos = DISPATCH_QOS_UNSPECIFIED;
#if HAVE_PTHREAD_WORKQUEUE_QOS
dispatch_queue_t dq = dqu._dq;
if (likely(pp)) {
bool enforce = (flags & DISPATCH_BLOCK_ENFORCE_QOS_CLASS);
bool is_floor = (dq->dq_priority & DISPATCH_PRIORITY_FLAG_FLOOR);
bool dq_has_qos = (dq->dq_priority & DISPATCH_PRIORITY_REQUESTED_MASK);
if (enforce) {
pp |= _PTHREAD_PRIORITY_ENFORCE_FLAG;
qos = _dispatch_qos_from_pp_unsafe(pp);
} else if (!is_floor && dq_has_qos) {
pp = 0;
} else {
qos = _dispatch_qos_from_pp_unsafe(pp);
}
}
dc->dc_priority = pp;
#else
(void)dc; (void)dqu; (void)pp; (void)flags;
#endif
return qos;
}
复制代码
注意_dispatch_continuation_init函数中，参数dispatch_block_t work即为传入的notification block。
void *ctxt = _dispatch_Block_copy(work);
// xxxxxx
dc->dc_ctxt = ctxt;
复制代码
notification block实际存入了dispatch_continuation_t对象dc的dc_ctxt字段中了。
_dispatch_group_wake
DISPATCH_NOINLINE
static void
_dispatch_group_wake(dispatch_group_t dg, uint64_t dg_state, bool needs_release)
{
uint16_t refs = needs_release ? 1 : 0; // <rdar://problem/22318411>
if (dg_state & DISPATCH_GROUP_HAS_NOTIFS) {
dispatch_continuation_t dc, next_dc, tail;
// Snapshot before anything is notified/woken <rdar://problem/8554546>
dc = os_mpsc_capture_snapshot(os_mpsc(dg, dg_notify), &tail);
do {
dispatch_queue_t dsn_queue = (dispatch_queue_t)dc->dc_data;
next_dc = os_mpsc_pop_snapshot_head(dc, tail, do_next);
_dispatch_continuation_async(dsn_queue, dc,
_dispatch_qos_from_pp(dc->dc_priority), dc->dc_flags);
_dispatch_release(dsn_queue);
} while ((dc = next_dc));
refs++;
}
if (dg_state & DISPATCH_GROUP_HAS_WAITERS) {
_dispatch_wake_by_address(&dg->dg_gen);
}
if (refs) _dispatch_release_n(dg, refs);
}
#define os_mpsc_capture_snapshot(Q, tail) ({ \ os_mpsc_node_type(Q) _head = os_mpsc_get_head(Q); \ os_atomic_store(_os_mpsc_head Q, NULL, relaxed); \ /* 22708742: set tail to NULL with release, so that NULL write */ \ /* to head above doesn't clobber head from concurrent enqueuer */ \ *(tail) = os_atomic_xchg(_os_mpsc_tail Q, NULL, release); \ _head; \ })
#define os_mpsc_pop_snapshot_head(head, tail, _o_next) ({ \ typeof(head) _head = (head), _tail = (tail), _n = NULL; \ if (_head != _tail) _n = os_mpsc_get_next(_head, _o_next); \ _n; \ })
复制代码
经过 os_mpsc_pop_snapshot_head 的定义，以及 next_dc = os_mpsc_pop_snapshot_head(dc, tail, do_next); 这一句代码，能够看出_dispatch_group_wake函数的主要逻辑也就是对dispatch_continuation_t next_dc这个一个链表结构，依次取出其中的元素dispatch_continuation_t dc，执行函数调用_dispatch_continuation_async，这也就是触发notification block执行的实际代码。
_dispatch_continuation_async(dsn_queue, dc,
_dispatch_qos_from_pp(dc->dc_priority), dc->dc_flags);
复制代码
_dispatch_continuation_async
DISPATCH_ALWAYS_INLINE
static inline void
_dispatch_continuation_async(dispatch_queue_class_t dqu,
dispatch_continuation_t dc, dispatch_qos_t qos, uintptr_t dc_flags)
{
#if DISPATCH_INTROSPECTION
if (!(dc_flags & DC_FLAG_NO_INTROSPECTION)) {
_dispatch_trace_item_push(dqu, dc);
}
#else
(void)dc_flags;
#endif
return dx_push(dqu._dq, dc, qos);
}
复制代码
看这个dx_push(dqu._dq, dc, qos);
#define dx_push(x, y, z) dx_vtable(x)->dq_push(x, y, z)
#define dx_vtable(x) (&(x)->do_vtable->_os_obj_vtable)
复制代码
这个do_vtable是啥呢？即为以前构建dispatch_continuation_t对象的时候，其中的DISPATCH_CONTINUATION_HEADER宏定义中的字段。
union { \
const void *do_vtable; \
uintptr_t dc_flags; \
}; \
复制代码
#define DISPATCH_QUEUE_VTABLE_HEADER(x); \ DISPATCH_OBJECT_VTABLE_HEADER(x); \ void (*const dq_activate)(dispatch_queue_class_t, bool *allow_resume); \ void (*const dq_wakeup)(dispatch_queue_class_t, dispatch_qos_t, \ dispatch_wakeup_flags_t); \ void (*const dq_push)(dispatch_queue_class_t, dispatch_object_t, \ dispatch_qos_t)
复制代码
因此，由此能够看出，在_dispatch_group_wake调用时，经过将notification block丢入（dx_push）到指定的queue中，则完成了GCD group的一个完整流程。
_dispatch_workloop_push
关于 #define dx_push(x, y, z) dx_vtable(x)->dq_push(x, y, z) ，经过DISPATCH_VTABLE_INSTANCE宏将dq_push与_dispatch_workloop_push关联起来。
DISPATCH_VTABLE_INSTANCE(workloop,
.do_type = DISPATCH_WORKLOOP_TYPE,
.do_dispose = _dispatch_workloop_dispose,
.do_debug = _dispatch_queue_debug,
.do_invoke = _dispatch_workloop_invoke,
.dq_activate = _dispatch_queue_no_activate,
.dq_wakeup = _dispatch_workloop_wakeup,
.dq_push = _dispatch_workloop_push,
);
复制代码
_dispatch_workloop_push的函数原型以下：
void
_dispatch_workloop_push(dispatch_workloop_t dwl, dispatch_object_t dou,
dispatch_qos_t qos)
{
struct dispatch_object_s *prev;
if (unlikely(_dispatch_object_is_waiter(dou))) {
return _dispatch_workloop_push_waiter(dwl, dou._dsc, qos);
}
if (qos < _dispatch_priority_qos(dwl->dq_priority)) {
qos = _dispatch_priority_qos(dwl->dq_priority);
}
if (qos == DISPATCH_QOS_UNSPECIFIED) {
qos = _dispatch_priority_fallback_qos(dwl->dq_priority);
}
prev = _dispatch_workloop_push_update_tail(dwl, qos, dou._do);
if (unlikely(os_mpsc_push_was_empty(prev))) {
_dispatch_retain_2_unsafe(dwl);
}
_dispatch_workloop_push_update_prev(dwl, qos, prev, dou._do);
if (unlikely(os_mpsc_push_was_empty(prev))) {
return _dispatch_workloop_wakeup(dwl, qos, DISPATCH_WAKEUP_CONSUME_2 |
DISPATCH_WAKEUP_MAKE_DIRTY);
}
}
复制代码
前边的 dx_push(dqu._dq, dc, qos); 即等同于 _dispatch_workloop_push(dqu._dq, dc, qos); 操做。
调用_dispatch_workloop_push即完成了将dispatch_continuation_t对象dc丢到dispatch_queue_class_t的_dq中（queue），同时还有qos参数。
至于queue中的block的实际执行代码，要继续从GCD源码找答案了。这里先埋一个坑，之后再填吧！
参考资料
相关文章
- 1. GCD源码分析
- 2. GCD源码原理分析
- 3. ThreadLocal 面试翻车现场
- 4. 分析一次double强转float的翻车缘由
- 5. dubbo的一次请求源码分析
- 6. iOS GCD源码浅析
- 7. 停车场分析
- 8. springBoot从入门到源码分析
- 9. HashMap从认识到源码分析
- 10. NIO 源码分析(03) 从 BIO 到 NIO
- 更多相关文章...
- • TiDB数据库的应用场景 - NoSQL教程
- • 高并发系统的分析和设计 - 红包项目实战
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • ☆基于Java Instrument的Agent实现
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. GCD源码分析
- 2. GCD源码原理分析
- 3. ThreadLocal 面试翻车现场
- 4. 分析一次double强转float的翻车缘由
- 5. dubbo的一次请求源码分析
- 6. iOS GCD源码浅析
- 7. 停车场分析
- 8. springBoot从入门到源码分析
- 9. HashMap从认识到源码分析
- 10. NIO 源码分析(03) 从 BIO 到 NIO