为什么没有在控制台应用程序中捕获默认的 SynchronizationContext？

Question

我正在尝试了解有关 SynchronizationContext 的更多信息，因此我制作了这个简单的控制台应用程序：

private static void Main()
{
    var sc = new SynchronizationContext();
    SynchronizationContext.SetSynchronizationContext(sc);
    DoSomething().Wait();
}

private static async Task DoSomething()
{
    Console.WriteLine(SynchronizationContext.Current != null); // true
    await Task.Delay(3000);
    Console.WriteLine(SynchronizationContext.Current != null); // false! why ?
}

如果我理解正确，await 运算符会捕获当前的 SynchronizationContext，然后将其余的异步方法发布给它。

但是，在我的应用程序中，SynchronizationContext.Current 在 await 之后为空。这是为什么？

编辑：

即使我使用自己的 SynchronizationContext 它也没有被捕获，尽管它的 Post 函数被调用了。这是我的 SC：

public class MySC : SynchronizationContext
{
    public override void Post(SendOrPostCallback d, object state)
    {
        base.Post(d, state);
        Console.WriteLine("Posted");
    }
}

这就是我的使用方式：

var sc = new MySC();
SynchronizationContext.SetSynchronizationContext(sc);

谢谢！

Answer 1

默认情况下，控制台应用程序和Windows服务中的所有线程只有默认的SynchronizationContext。

请参阅 MSDN 文章 Parallel Computing - It's All About the SynchronizationContext。这有关于各种应用程序中 SynchronizationContext 的详细信息。

Answer 2

详细说明已经指出的内容。

您在第一个代码片段中使用的 SynchronizationContext class 是 default 实现，它不执行任何操作。

在第二个代码片段中，您创建自己的 MySC 上下文。但是你错过了真正让它发挥作用的部分：

public override void Post(SendOrPostCallback d, object state)
{
    base.Post(state2 => {
        // here we make the continuation run on the original context
        SetSynchronizationContext(this); 
        d(state2);
    }, state);        
    Console.WriteLine("Posted");
}

Answer 3

"capture"这个词太晦涩了，听起来太像框架应该做的事情了。具有误导性，因为它通常出现在使用默认 SynchronizationContext 实现之一的程序中。喜欢one you get in a Winforms app。但是当你自己写的时候，框架就不再有帮助了，这就成了你的工作。

async/await 管道为上下文提供了在特定线程上运行延续（等待之后的代码）的机会。这听起来像是一件微不足道的事情，因为你以前经常这样做，但实际上很难。不可能任意中断该线程正在执行的代码，那会导致可怕的重入错误。跟帖求助，需要解决标准producer-consumer problem。采用线程安全队列和清空该队列的循环，处理调用请求。重写的 Post 和 Send 方法的工作是将请求添加到队列中，线程的工作是使用循环清空它并执行请求。

Winforms、WPF或UWP应用程序的主线程都有这样一个循环，由Application.Run()执行。具有相应的 SynchronizationContext，它知道如何为它提供调用请求，分别是 WindowsFormsSynchronizationContext、DispatcherSynchronizationContext 和 WinRTSynchronizationContext。 ASP.NET 也可以做到，使用 AspNetSynchronizationContext。所有这些都由框架提供，并由 class 库管道自动安装。他们在构造函数中捕获同步上下文，并在 Post 和 Send 方法中使用 Begin/Invoke。

当您编写自己的 SynchronizationContext 时，您现在必须处理这些细节。在您的代码片段中，您没有覆盖 Post 和 Send 而是继承了基本方法。他们什么都不知道，只能在任意线程池线程上执行请求。所以 SynchronizationContext.Current 现在在该线程上为空，线程池线程不知道请求来自何处。

创建您自己的并不难，ConcurrentQueue 和委托有助于减少代码量。很多程序员都这样做了，this library 经常被引用。但是要付出沉重的代价，调度程序循环从根本上改变了控制台模式应用程序的行为方式。它阻塞线程直到循环结束。就像 Application.Run() 一样。

您需要一种截然不同的编程风格，即您熟悉的 GUI 应用程序风格。代码不能花费太长时间，因为它会破坏调度程序循环，从而阻止调用请求被调度。在 GUI 应用程序中，由于 UI 变得无响应而非常明显，在您的示例代码中，您会注意到您的方法完成速度很慢，因为继续不能运行一段时间.你需要一个工作线程来分拆慢代码，天下没有免费的午餐。

值得注意的是为什么存在这些东西。 GUI 应用程序有一个严重的问题，它们的 class 库从来不是线程安全的，也不能通过使用 lock 来保证安全。正确使用它们的唯一方法是从同一个线程进行所有调用。 InvalidOperationException 当你不这样做时。他们的调度程序循环可以帮助您做到这一点，为 Begin/Invoke 和 async/await 提供支持。控制台没有这个问题，任何线程都可以向控制台写入一些东西，锁可以帮助防止它们的输出混合在一起。因此，控制台应用程序不应需要自定义 SynchronizationContext。 YMMV.

Answer 4

实现您自己的 SynchronizationContext 是可行的，但并非易事。使用现有的实现要容易得多，例如 Nito.AsyncEx.Context 包中的 AsyncContext class。你可以这样使用它：

using System;
using System.Threading;
using System.Threading.Tasks;
using Nito.AsyncEx;

public static class Program
{
    static void Main()
    {
        AsyncContext.Run(async () =>
        {
            await DoSomethingAsync();
        });
    }

    static async Task DoSomethingAsync()
    {
        Console.WriteLine(SynchronizationContext.Current != null); // True
        await Task.Delay(3000);
        Console.WriteLine(SynchronizationContext.Current != null); // True
    }
}

Try it on Fiddle.

AsyncContext.Run是一种阻塞方法。它会在提供的异步委托 Func<Task> action 完成时完成。如果没有 Task.Run 或 ConfigureAwait(false) 会强制您的代码退出上下文，则所有异步延续都将在控制台应用程序的主线程上运行。

在控制台应用程序中使用单线程 SynchronizationContext 的后果是：

您将不再需要担心线程安全，因为您的所有代码都将汇集到一个线程中。
您的代码容易受到 deadlocks 的影响。代码中的任何 .Wait()、.Result、.GetAwaiter().GetResult() 等很可能会导致您的应用程序冻结，在这种情况下，您必须从 Windows 任务管理器。

为什么没有在控制台应用程序中捕获默认的 SynchronizationContext？

Why the default SynchronizationContext is not captured in a Console App?

c#

console-application

synchronizationcontext

async-await