任務vs線程池

Question

我有一個應用程序在C＃與工作列表。我正在尋求儘可能多的並行工作。不過，我需要能夠控制最大並行任務數量。

從我的理解，這是可能的一個線程池或任務。我使用哪一種有區別？我主要關心的是能夠一次控制有多少線程處於活動狀態。

Answer 1

請看一看ParallelOptions.MaxDegreeOfParallelism爲Task秒。

我建議你使用任務，因爲它們提供比ThreadPool更高級別的抽象。

關於這個話題的一個很好的閱讀可以找到here。真的，一本必備的書，它是免費的:)

Answer 2

您也可以創建一個信號量來控制一次可以執行多少個線程。您可以創建一個新的信號量，並在構造函數中指定同時有多少個併發線程可以一次使用該信號量。由於我不知道你將如何使用這些線程，這將是一個很好的起點。

MSDN Article on the Semaphore class

-Wesley

Answer 3

在這article on msdn，他們解釋了爲什麼他們推薦任務而不是ThreadPool for Parallelism。

Answer 4

任務有一個非常迷人的功能給我，你可以建立任務鏈。以前的任務的某些結果被執行。 我經常使用的功能如下：任務A在後臺運行，以執行一些長時間運行的工作。我之後鏈接任務B，僅在任務A完成regulary並且將其配置爲在前臺運行時才執行，因此我可以輕鬆更新我的控件，並使用長時間運行的任務A的結果。

Answer 5

在TPL中，您可以使用WithDegreeOfParallelism在ParallelEnumerable或ParallelOptions.MaxDegreeOfParallism

還有CountdownEvent如果您只是使用自定義線程或任務，這可能是一個更好的選擇。

在ThreadPool中，當您使用SetMaxThreads時，它的全局值爲AppDomain，因此您可能會不必要地限制不相關的代碼。

您不能將工作線程數或I/O完成線程數設置爲小於計算機中處理器數的數字。

如果公共語言運行庫由例如Internet信息服務（IIS）或SQL Server託管，則主機可以限制或防止更改線程池大小。

更改線程池中的最大線程數時請謹慎使用。雖然您的代碼可能會受益，但這些更改可能會對您使用的代碼庫產生不利影響。

將線程池大小設置過大可能會導致性能問題。如果太多線程同時執行，任務切換開銷就成爲一個重要因素。

我同意其他答案，您應該使用TPL而不是ThreadPool作爲多線程的更好的抽象，但是它有可能在兩者中實現您想要的。