使用任務和線程池可以嗎？

Question

讀取線程池和任務this文章是如何工作後，我想出了這個問題 -

如果非要在其中一些模塊使用tasks一個複雜的程序和一些使用thread pool，有沒有可能會有一些由於不同的用途而調度問題？

Answer 1

不，實際上在混合方法中，內存或性能低效率方面沒有多少限制;默認情況下，任務使用線程池線程使用的相同線程池。

混合兩者的唯一明顯缺點是代碼庫缺乏一致性。如果你選擇一個，我會使用TPL，因爲它有一個豐富的API來處理多線程的許多方面，並利用異步/等待語言功能。

由於您的用法被劃分爲模塊行，因此您無需擔心太多事情。

Answer 2

不，不會有問題 - 你只是兩個效率都不高。使用真正需要的東西並堅持這種模式。請記住，無論您使用哪種線程算法，確保您還可以讓您的應用程序MT安全，尤其是在您訪問來自不同線程的相同資源/變量等時。

Answer 3

任務通常是使用線程池實現的（當然也可以使用其他類型的調度程序給出不同的行爲，但這是默認的）的任務。根據正在執行的實際代碼（假設您的任務代表正在運行的代表），實際上沒有太大的區別。

任務只是簡單地創建一個圍繞該線程池調用的包裝，以便在收集有關該異步操作的信息並處理其結果時提供額外的功能。如果你想利用這些額外的功能，然後使用任務。如果你不需要在特定的上下文中使用它，直接使用線程池沒有任何問題。

把兩者混合起來，只要你沒有麻煩從這些操作的結果中得到你想要的東西，根本不是問題。

Answer 4

不應該有任何調度問題，但當然最好使用任務並讓框架決定如何處理預定的工作。在當前版本的框架（4.5）中，除非使用LongRunning選項，否則該工作將通過ThreadPool排隊，但這種行爲在將來當然可能會發生變化。

結論：混合任務和ThreadPool不是問題，但對於新應用程序，建議使用任務而不是直接在ThreadPool上排隊工作項目（其中一個原因是ThreadPool在Windows 8 Runtime中不可用）現代UI應用程序）