为什么 ThreadPool 决定使用名为 Task.Wait 的确切上下文线程？

Question

为什么 ThreadPool 决定使用名为 Task.Wait 的确切上下文线程？

有the question。由于某些原因，我既没有看到问题的评论按钮，也没有看到任何答案的评论按钮。所以，我在一个单独的线程中问了一个相关的问题。

在链接的问题中有一个指向the blog 的答案。根据此博客，以下声明成立。

有代码片段：

// My "library" method.
public static async Task<JObject> GetJsonAsync(Uri uri)
{
  // (real-world code shouldn't use HttpClient in a using block; this is just example code)
  using (var client = new HttpClient())
  {
    var jsonString = await client.GetStringAsync(uri);
    return JObject.Parse(jsonString);
  }
}

// My "top-level" method.
public void Button1_Click(...)
{
  var jsonTask = GetJsonAsync(...);
  textBox1.Text = jsonTask.Result;
}

还有死锁发生的解释：

1. 顶级方法调用GetJsonAsync（在 UI/ASP.NET 上下文中）。
2. GetJsonAsync 通过调用 HttpClient.GetStringAsync（仍在上下文中）启动 REST 请求。
3. GetStringAsync 返回未完成的Task，表示 REST 请求未完成。
4. GetJsonAsync 等待由 GetStringAsync 返回的 Task。上下文被捕获并将用于稍后继续运行GetJsonAsync 方法。 GetJsonAsync返回一个未完成的Task，表示GetJsonAsync方法没有完成。
5. 顶级方法同步阻塞GetJsonAsync 返回的任务。这会阻塞上下文线程。
6. ... 最终，REST 请求将完成。这完成了由GetStringAsync 返回的Task。
7. GetJsonAsync 的延续现在已准备好运行，它等待上下文可用，以便在上下文中执行。
8. 死锁。顶级方法是阻塞上下文线程，等待GetJsonAsync 完成，而GetJsonAsync 正在等待上下文空闲以便它可以完成。

我的问题特别是关于第 7 步。为什么ThreadPool 决定采用一个阻塞的线程并等待它解除阻塞以要求该线程运行代码？为什么不直接拿其他线程呢？

Answer 1

GetJsonAsync 不在任意线程池线程上执行。它在上下文线程上执行。

根据示例代码，任务GetJsonAsync 由按钮单击事件创建，该事件在 UI 线程（上下文线程）上执行。等待任务时，会捕获当前上下文（在本例中为 UI 同步上下文）。任务完成后，继续在同一上下文中继续。

在第7步，任务尝试返回UI线程，但UI线程被.Result阻塞，等待任务返回。于是就发生了死锁。

我注意到引用的问题是关于 ASP.NET WebApi 应用程序的问题。所以只想澄清几点：

ASP.Net WebAPI 确实有一个特殊的同步上下文，但它不同于 UI 上下文。只有一个 UI 线程，因此上下文仅将回调/延续调度到 UI 线程。

但是，ASP.Net WebAPI 的同步上下文不捕获单个线程。 ASP.Net 代码可以在不同/任意线程上运行。上下文负责恢复线程数据并确保以先到先得的方式将延续链接在一起。