從一次翻車現場到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