第 9 頻道對任務與線程的解釋是否正確？

Question

有一個Channel 9 Video試圖解釋線程和任務之間的區別。 我通常喜歡第 9 頻道的視頻，因為它們的技術准確性，但據我所知，這個視頻的一些關鍵陳述是錯誤的。

以下是聲明：

1. @~1:48 到 ~2:30：線程在內存和時間上都很昂貴。 每個線程獲得 1 MB 的用戶模式堆棧。
2. @~2:30 到 2:37：創建線程也需要時間。 是時候分配數據結構並初始化它們了。
3. @~2:38 到 2:45：上下文切換也需要時間。
4. @~2:58 到 3:23 和 3:48 到：任務使用多核系統 [...] 因此，當您進行計算時，您使用的是多核。
5. @~5:02 到 5:30：線程在單核上運行，上下文切換發生很多。
6. @~5:40 到 5:51：線程有不同的執行方式。 它們在多個內核上執行。
7. @~6:20 到 6:30：正如您在圖中看到的，線程處理有開銷。

以下是我想確認或否定的想法：

1. 調用堆棧的數量是可配置的。 這樣，對於 32 位進程，線程限制不是 ~1300，而是高達 12000。 那些擁有 SysInternals TestLimit 副本的人可以嘗試一下：

    D:\\>testlimit -t -n 64 Testlimit v5.04 - test Windows limits By Mark Russinovich - www.sysinternals.com Creating threads with 64 KB stacks... Created 12500 threads. Lasterror: 8

   堆棧大小也在.NET的線程構造函數中公開

2. 任務依賴於線程作為基礎。 那些線程是從線程池中取出來的，但是，線程池的線程需要先創建后才能使用。 AFAIK，Mark Russinovich 在 Windows Internals 一書中也解釋過，內核結構（ _ETHREAD ）保存在內存中以供重用。 這最大限度地減少了分配的開銷並將其減少到初始化。

   我沒有找到我正在尋找的確切位置，但在 Windows Internals 6，第 1 部分中，它在第 417 頁上說：

   [...] 執行線程對象可能會或可能不會被釋放。

3. 由於 Task 依賴於線程作為技術實現，因此無論如何都會發生上下文切換。

4. 如果我有 2 個線程，它們也可以在不同的處理器上執行。 恕我直言，這就是它的全部想法。

5. 演講者正在討論單核系統上的線程。 恕我直言，在這種情況下，任務也幾乎沒有任何好處。 見 4。）

6. 見 4. 和 5。）

7. 幻燈片可能是正確的，但它沒有顯示出真正的原因。 該幻燈片缺少導致上下文切換的 ~15 ms 時間片。 如果線程需要等待結果，則只能使用任務來減少開銷。

   在這種情況下，幻燈片的下半部分也不正確，因為工作 1 的第一部分似乎被阻塞，在這種情況下，工作 2 只能執行。 當工作 2 完成時，可能滿足繼續工作 1 的條件。 只有當所有這些都發生在一個時間片內時，任務才有好處。

   無論如何，任務也遲早會發生上下文切換。

我已經嘗試在 SO 上的這些問題的幫助下確認我的理解

• 任務與線程差異
• 任務和線程有什么區別

以上可能看起來像是 7 個單獨的問題。 我在一處詢問了他們，​​因為

• 在一個視頻中都有他們的來源
• 有些問題相互依賴
• 恕我直言，在一個地方找到信息比遵循一次提出一個問題的 SO 規則更重要。

Answer 1

注意：還沒有觀看視頻，純粹基於 OP 中的信息。

調用堆棧的數量是可配置的。

可能，但不是真正相關，除非我們進入非常詳細的細節。

對於 .NET 任務依賴於線程作為基礎。 那些線程是從線程池中取出來的，但是，線程池的線程需要先創建后才能使用。

有點正確……盡管我們需要在抽象和實現之間保持非常清晰的界限。 任務可以使用.Net中的Threadpool來執行更正確。

任務代表了一個自包含代碼段的想法，它（通常）可以與其他代碼並發運行。 線程是類似性質的操作系統實現。

由於 Task 依賴於線程作為技術實現，因此無論如何都會發生上下文切換。

不正確。 雖然任務可以在線程上運行，並且可以發生上下文切換，但任務包含一個提供更多靈活性的抽象層。

例如，要在線程之間交換執行，必須在硬件中進行上下文切換。 要在任務之間交換執行，不必發生此類硬件上下文切換。 任務可以在不同線程之間移動、休眠和恢復，無需單個硬件上下文切換。

如果我有 2 個線程，它們也可以在不同的處理器上執行。 恕我直言，這就是它的全部想法。

正確的。

演講者正在談論單核系統上的線程。 恕我直言，在這種情況下，任務也幾乎沒有任何好處。

不正確。 任務在單線程系統上運行良好，因為它們只是一個抽象。 此外，您可以在單個線程中運行多個任務，而無需任何硬件上下文切換，這可能會提高性能。

---

這里的主要概念問題似乎是 Task = Thread 的想法。 不是這種情況。 任務是分解工作的概念方式。 線程是具有某些行為特征的類似想法的實現。 雖然任務可以在幕后線程上運行（不一定），但抽象允許它們以與硬件線程非常不同的方式運行。