當所有正在運行的任務正在等待時，GCD死鎖不會啓動掛起的任務

Question

我有一個遞歸函數，用於在併發隊列上調度新任務。我想限制同時計劃任務的數量，所以我使用一個信號量，以便每個任務都會等待，直到舊線程結束併發出信號燈信號。

但是我發現當達到最大運行線程數（64）並且它們都開始在信號量上等待時，隊列會死鎖。然後GCD不會開始新的任務，即使它的待處理隊列中有很多。

我在做什麼錯？這是我的代碼：

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification 
{ 
    dispatch_semaphore_t sem = dispatch_semaphore_create(10); 

    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER); 

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),^
       { 
        [self recurWithSemaphore:sem]; 
       }); 
} 

- (void)recurWithSemaphore:(dispatch_semaphore_t)sem 
{ 
    // do some lengthy work here... 

    // at this point we're done all but scheduling new tasks so let new tasks be created 
    dispatch_semaphore_signal(sem); 

    for (NSUInteger i = 0; i < 100; ++i) 
    { 
     // don't schedule new tasks until we have enough semaphore 
     dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER); 

     dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),^
        { 
         [self recurWithSemaphore:sem]; 
        }); 
    } 
} 

Answer 1

典型模式使用信號量時來控制訪問有限的資源是

• 創建具有非零值信號;

• 對於每一個任務：

  • 在啓動時，「等待」信號量（從而消耗可用的信號中的一個，或者如果一個不可用，等待一個）;和

  • 完成後，「信號」信號量（使其可用於其他任務）。

所以，讓我們說，你想開百萬的任務，只有4個同時在任何給定的時間，你可以這樣做：

dispatch_semaphore_t semaphore = dispatch_semaphore_create(4); 

dispatch_queue_t queue = ... // some concurrent queue, either global or your own 

dispatch_async(queue, ^{ 
    for (long index = 0; index < 1000000; index++) { 
     dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); 
     dispatch_async(queue, ^{ 
      [self performSomeActionWithIndex:index completion:^{ 
       dispatch_semaphore_signal(semaphore); 
      }]; 
     }); 
    } 
}); 

很顯然，如果你動態地添加要執行更多任務，您可以將其從for循環更改爲while循環，檢查一些同步源，但是這個想法是相同的。

但關鍵的觀察是，我沒有performSomeActionWithIndex本身，它本身遞歸地創建任務本身（因爲然後你進入原始問題的死鎖情況，因爲任務停止，因爲它們無法啓動新任務）。

現在，我不知道你的問題是否可以重構爲這種模式，但如果可以的話，這可能是一個選擇。

---

順便說一句，爲了完整起見，我要指出的是，用於控制併發度的典型解決方案是使用操作隊列，而不是調度隊列，在這種情況下，你可以指定maxConcurrentOperationCount。

正如您正確指出的那樣，存在內存影響。在我的測試中，每個計劃的操作至少佔用500個字節（在現實世界中可能更多），因此如果您確實有超過5,000-10,000個任務需要調度，操作隊列可能很快變得不切實際。如您所知，未來的讀者應參考併發編程指南：併發和應用程序設計中的Performance Implications部分。

我知道這不是一個可行的方法在你的情況，但我只提到它爲未來的讀者的利益。當需要控制併發程度時，我通常會建議使用操作隊列。如果您處理的任務太多，以至於無法合理地將它們安排在操作隊列中，我只會跳到上面所述的方法。