為什么 Swift 不在啟動的同一線程上恢復異步 function？

Question

在“The Swift Programming Language”並發章節的介紹部分，我讀到：

當異步 function 恢復時，Swift 不保證 function 將在哪個線程上運行。

這讓我很吃驚。 這看起來很奇怪，例如與 pthreads 中等待信號量相比，執行可以跳轉線程。

這使我想到以下問題：

• 為什么 Swift 不保證在同一個線程上恢復？

• 是否有任何規則可以確定恢復線程？

• 有沒有辦法影響這種行為，例如確保它在主線程上恢復？

編輯：我對 Swift 並發性的研究以及上面的后續問題是通過發現從主線程（在 SwiftUI 中）上運行的代碼開始的Task正在另一個線程上執行它的塊而觸發的。

Answer 1

它有助於在某些上下文中接近 Swift 並發：Swift 並發嘗試提供一種更高級別的方法來處理並發代碼，並代表您可能已經習慣的線程模型和線程的低級別管理，並發原語（鎖定、信號量）等，這樣您就不必花任何時間考慮低級管理。

在 TSPL 的Actors 部分，在您引用的頁面下方一點：

您可以使用任務將您的程序分解為孤立的、並發的部分。 任務彼此隔離，這使得它們可以安全地同時運行……

在 Swift Concurrency 中， Task代表可以並發完成的隔離工作，這里隔離的概念非常重要：當代碼與其周圍的上下文隔離時，它可以完成所需的工作而不會產生影響在外面的世界，或受到它的影響。 這意味着在理想情況下，真正隔離的任務可以隨時在任何線程上運行，並根據需要跨線程交換，而不會對正在完成的工作（或程序的 rest）產生任何可衡量的影響。

正如@Alexander 在上面的評論中提到的，如果做得好，這是一個巨大的好處：當以這種方式隔離工作時，任何可用的線程都可以接手該工作並執行它，讓您的流程有機會完成更多的工作，而不是等待特定線程可用。

然而：並非所有代碼都可以完全隔離以致於以這種方式運行； 在某些時候，一些代碼需要與外部世界交互。 在某些情況下，任務需要相互交互才能共同完成工作； 在其他情況下，如 UI 工作，任務需要與非並發代碼協調才能產生這種效果。 Actor是 Swift Concurrency 提供的工具來幫助進行這種協調。

Actor有助於確保任務在特定上下文中運行，相對於其他也需要在該上下文中運行的任務而言是連續的。 繼續上面的引用：

…這使它們可以安全地同時運行，但有時您需要在任務之間共享一些信息。 Actor 讓您可以在並發代碼之間安全地共享信息。

…actor 一次只允許一個任務訪問其可變的 state，這使得多個任務中的代碼與 actor 的同一個實例交互是安全的。

除了將Actor用作 state 的隔離避風港（如該部分的 rest 所示）之外，您還可以創建Task並使用它們應在其上下文中運行的Actor顯式注釋它們的主體。 例如，要使用 TSPL 的TemperatureLogger示例，您可以在TemperatureLogger的上下文中運行一個任務，如下所示：

Task { @TemperatureLogger in
    // This task is now isolated from all other tasks which run against
    // TemperatureLogger. It is guaranteed to run _only_ within the
    // context of TemperatureLogger.
}

針對MainActor運行也是如此：

Task { @MainActor in
    // This code is isolated to the main actor now, and won't run concurrently
    // with any other @MainActor code.
}

這種方法適用於可能需要訪問共享 state 並且需要彼此隔離的任務，但是：如果你對此進行測試，你可能會注意到針對同一個（非主要）actor 運行的多個任務可能仍在運行在多個線程上，或者可以在不同的線程上恢復。 是什么賦予了？

---

Task和Actor是 Swift 並發中的高級工具，它們是您作為開發人員接觸最多的工具，但讓我們進入實現細節：

1. Task實際上不是Swift 並發中 work 的低級原語； Job是。 Job表示await語句之間的Task中的代碼，您永遠不會自己編寫Job ； Swift 編譯器獲取Task並從中創建Job
2. Job本身不是由Actor運行的，而是由Executor運行的，同樣，您永遠不會自己直接實例化或使用Executor 。 但是，每個Actor都有一個與之關聯的Executor ，它實際運行提交給該 actor 的作業

這是調度實際發揮作用的地方。 目前Swift並發有兩個主要執行者：

1. 一個協作的全局執行器，它在協作線程池上安排作業，以及
2. 主執行器，專門在主線程上安排作業

所有非MainActor actor 目前都使用全局執行器來調度和執行作業，而MainActor使用主執行器來做同樣的事情。

作為Swift並發的用戶，這意味着：

1. 如果你需要一段代碼在主線程上獨占運行，你可以將它調度到MainActor上，它會保證只在該線程上運行
2. 如果您在任何其他Actor上創建任務，它將在全局協作線程池中的一個（或多個）線程上運行
   • 如果你針對特定的Actor運行， Actor將為你管理鎖和其他並發原語，這樣任務就不會同時修改共享 state

---

有了所有這些，就可以回答您的問題：

為什么 Swift 不保證在同一個線程上恢復？

正如上面評論中提到的——因為：

1. 它不應該是必要的（因為任務應該以“我們在哪個線程上？”的細節無關緊要的方式隔離），並且
2. 能夠使用任何一個可用的協作線程意味着您可以更快地繼續完成所有工作

但是，“主線程”在很多方面都很特殊，因此， @MainActor只能使用該線程。 當您確實需要確保您獨占主線程時，您可以使用主要參與者。

是否有任何規則可以確定恢復線程？

非@MainActor任務的唯一規則是：協作線程池中的第一個可用線程將接手工作。

更改此行為需要編寫和使用您自己的Executor ，這不太可能（ 盡管有一些計划使這成為可能）。

有沒有辦法影響這種行為，例如確保它在主線程上恢復？

對於任意線程，不——您需要提供自己的執行程序來控制底層細節。

但是，對於主線程，您有幾個工具：

1. 當你使用Task.init(priority:operation:)創建一個Task時，它默認繼承當前的 actor，無論這個 actor 是什么。 這意味着如果您已經在主要演員上運行，任務將繼續使用當前演員； 但如果你不是，它就不會。 要顯式注釋您希望任務在主要參與者上運行，您可以顯式注釋其操作：

    Task { @MainActor in //... }

   這將確保無論Task是在哪個 actor 上創建的，包含的代碼都只會在主要 actor 上運行。

2. 在Task中：無論您當前在哪個 actor 上，您始終可以使用MainActor.run(resultType:body:)將作業直接提交給主要 actor。 body閉包已經被注釋為@MainActor ，並且將保證在主線程上執行

請注意，創建分離任務永遠不會從當前參與者繼承，因此保證分離任務將通過全局執行程序隱式調度。

我對 Swift 並發性的研究以及上面的后續問題是通過發現從主線程（在 SwiftUI 中）上運行的代碼開始的任務正在另一個線程上執行它的塊而觸發的。

這將有助於在此處查看具體代碼以准確解釋發生了什么，但有兩種可能性：

1. 您創建了一個非顯式@MainActor的Task ，它恰好在當前線程上開始執行。 然而，因為你沒有綁定到主要演員，它碰巧被其中一個合作線程暫停和恢復
2. 您創建了一個Task ，其中包含其他Task ，這些 Task 可能已經在其他參與者上運行，或者是明確分離的任務——並且該工作在另一個線程上繼續

---

要更深入地了解這里的細節，請查看Swift 並發性：WWDC2021 的幕后，@Rob 在評論中鏈接。 關於正在發生的事情的細節還有很多，獲得更底層的視圖可能會很有趣。

Answer 2

如果您想深入了解底層 Swift 並發的線程 model，請觀看 WWDC 2021 視頻Swift 並發：幕后。

在回答你的幾個問題時：

1. 為什么 Swift 不保證在同一個線程上恢復？

因為，作為一種優化，在某個已經在 CPU 內核上運行的線程上運行它通常會更有效率。 正如他們在該視頻中所說：

當線程在 Swift 並發下執行工作時，它們會在延續之間切換，而不是執行完整的線程上下文切換。 這意味着我們現在只需支付 function 呼叫的費用。 ……

你go上去問：

2. 是否有任何規則可以確定恢復線程？

除了主要演員，不，不能保證它使用哪個線程。

（順便說一句，我們已經在這種環境中生活了很長時間。值得注意的是，除了主隊列之外，GCD 調度隊列無法保證調度到特定串行隊列的兩個塊將在同一隊列上運行線程，要么。）

3. 有沒有辦法影響這種行為，例如確保它在主線程上恢復？

如果我們需要在主要參與者上運行某些東西，我們只需將該方法隔離到主要參與者（在閉包、方法或封閉類上使用@MainActor指定）。 理論上，也可以使用MainActor.run {…} ，但這通常是錯誤的解決方法。