死鎖風險

Question

看看下面的天真實現一個嵌套的異步循環使用線程池：

ThreadPool.SetMaxThreads(10, 10); 
CountdownEvent icnt = new CountdownEvent(1); 
for (int i = 0; i < 50; i++) 
{ 
    icnt.AddCount(); 
    ThreadPool.QueueUserWorkItem((inum) => 
    { 
     Console.WriteLine("i" + inum + " scheduled..."); 
     Thread.Sleep(10000); // simulated i/o 
     CountdownEvent jcnt = new CountdownEvent(1); 
     for (int j = 0; j < 50; j++) 
     { 
      jcnt.AddCount(); 
      ThreadPool.QueueUserWorkItem((jnum) => 
      { 
       Console.WriteLine("j" + jnum + " scheduled..."); 
       Thread.Sleep(20000); // simulated i/o 
       jcnt.Signal(); 
       Console.WriteLine("j" + jnum + " complete."); 
      }, j); 
     } 
     jcnt.Signal(); 
     jcnt.Wait(); 
     icnt.Signal(); 
     Console.WriteLine("i" + inum + " complete."); 
    }, i); 
} 
icnt.Signal(); 
icnt.Wait(); 

現在，你永遠不會使用此模式（它會僵局的開始），但它確實證明一個特定的死鎖可能會導致線程池 - 通過在阻塞線程消耗完整個池之後等待嵌套線程完成時阻塞。

我不知道是否有使用這個嵌套的Parallel.For版本產生同樣有害的行爲的任何潛在風險：

Parallel.For(1, 50, (i) => 
{ 
    Console.WriteLine("i" + i + " scheduled..."); 
    Thread.Sleep(10000); // simulated i/o 
    Parallel.For(1, 5, (j) => 
    { 
     Thread.Sleep(20000); // simulated i/o 
     Console.WriteLine("j" + j + " complete."); 
    }); 
    Console.WriteLine("i" + i + " complete."); 
}); 

顯然調度機制更爲複雜（我沒見過這個版本完全死鎖），但潛在的風險似乎仍然潛伏在那裏。是否理論上有可能通過依賴嵌套線程來幹化Parallel.For所使用的池以達到創建死鎖的目的？即Parallel.For保留在延遲後計劃的作業的後面口袋中的線程數是否有限制？

Answer 1

不，不存在像Parallel.For()（或Parallel.ForEach()）那樣的死鎖風險。

有一些因素會降低死鎖的風險（如使用的線程的動態計數）。但是，死鎖是不可能的，這也是一個原因：迭代也在原始線程上運行。這意味着如果ThreadPool完全忙，則計算將完全同步運行。在這種情況下，使用Parallel.For()時你不會得到任何加速，但是你的代碼仍然可以運行，沒有死鎖。

而且，與Task提供了一個類似的情況也正確解決：如果你Wait()在Task（或訪問其Result），其尚未排定，它會在當前線程串聯模式運行。我認爲這主要是性能優化，但我認爲它也可以避免在某些特定情況下的死鎖。

但我認爲這個問題比實際更理論化。 .Net 4 ThreadPool的默認最大線程數設置爲大約一千。如果你在同一時間阻止了一千個Thread，那麼你正在做一件非常錯誤的事情。