c# - 为什么没有在控制台应用程序中捕获默认的 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

“捕获”这个词太不透明了，听起来太像框架应该做的事情了。具有误导性，因为它通常出现在使用默认 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。所有这些都由框架提供，并由类库管道自动安装。他们在构造函数中捕获同步上下文，并在其 Post 和 Send 方法中使用 Begin/Invoke。

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

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

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

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