传输事件处理程序中的 SynchronizationContext.Post(...)

Question

我们有一个方法，由于客户端应用程序中的线程需要使用 SynchronizationContext。

我的一位同事编写的一些代码对我来说“感觉”不正确，性能分析器告诉我，在这段代码中使用了很多处理。

void transportHelper_SubscriptionMessageReceived(object sender, SubscriptionMessageEventArgs e)
        {
            if (SynchronizationContext.Current != synchronizationContext)
            {
                synchronizationContext.Post(delegate
                     {
                         transportHelper_SubscriptionMessageReceived(sender, e);
                     }, null);

                return;
            }
  [code removed....]
}

这对我来说感觉不太对劲，因为我们基本上将相同的请求发布到 gui 线程事件队列...但是，除了该代码区域的性能之外，我也看不到任何明显的问题。

此方法是一个事件处理程序，附加到由我们的中间层消息传递层帮助程序 (transportHelper) 引发的事件，并且它存在于处理来自 GUI 的请求的服务中。

这看起来是一种可以接受的确保我们不会出现跨线程错误的方法吗？ 如果没有，有更好的解决方案吗？

谢谢

Answer 1

让我们跟踪这个方法内部发生了什么，看看它告诉我们什么。

1. 方法签名遵循事件处理程序的签名，正如问题所示，我们可以预期它会在非 UI 线程的某个线程的上下文中首先调用。

2. 该方法所做的第一件事是将其运行的线程的 SynchronizationContext 与保存在成员变量中的 SynchronizationContext 进行比较。 我们假设保存的上下文是 UI 线程的上下文。 （Mike Peretz 在 CodeProject 上发布了一系列有关 SynchronizationContext 类的精彩介绍文章）

3. 该方法会发现上下文不相等，因为它是在与 UI 线程不同的线程中调用的。 调用线程的上下文可能为 null，其中 UI 线程的上下文几乎可以保证设置为 WindowsFormsSynchronizationContext 的实例。 然后，它将在 UI 上下文上发出 Post()，将委托传递给自身及其参数，并立即返回。 这完成了后台线程上的所有处理。

4. Post() 调用会导致在 UI 线程上调用完全相同的方法。 跟踪 WindowsFormsSynchronizationContext.Post() 的实现表明，这是通过在 UI 线程的消息队列上排队自定义 Windows 消息来实现的。 参数会被传递，但不会被“封送”，因为它们不会被复制或转换。

5. 由于 Post() 调用的结果，我们的事件处理程序方法现在被再次调用，并且参数完全相同。 然而，这一次，线程的 SynchronizationContext 和保存的上下文是同一个。 if 子句的内容被跳过，并执行 [代码已删除] 部分。

这是一个好的设计吗？ 如果不知道[代码已删除]部分的内容，很难说。 以下是一些想法：

1. 从表面上看，这似乎并不是一个糟糕的设计。 消息在后台线程上接收，并传递到 UI 线程进行呈现。 调用者立即返回去做其他事情，而接收者则继续执行任务。 这有点类似于 Unix fork() 模式。

2. 该方法是递归的，以独特的方式。 它不会在同一线程上调用自身。 相反，它会导致不同的线程调用它。 与任何递归代码一样，我们会关心它的终止条件。 通过阅读代码，可以相当安全地假设，当传递给 UI 线程时，它始终会被递归调用一次。 但这是另一个需要注意的问题。 另一种设计可能会向 Post() 传递不同的方法（也许是匿名方法），并完全避免递归问题。

3. if 子句中发生大量处理似乎没有明显的原因。 使用 .NET 反射器 查看 Post() 的 WindowsFormsSynchronizationContext 实现，揭示了一些中等长度的序列其中有很多代码，但没有什么太奇特的； 这一切都发生在 RAM 中，并且不会复制大量数据。 本质上，它只是准备参数并将 Windows 消息放入接收线程的消息队列中。

   对于

4. 您应该检查该方法的[代码已删除]部分内发生的情况。 涉及 UI 控件的代码完全属于那里——它必须在 UI 线程内执行。 但是，如果其中有不处理 UI 的代码，那么让它在接收线程中执行可能是一个更好的主意。 例如，任何 CPU 密集型解析最好托管在接收线程中，这样不会影响 UI 响应能力。 您可以将这部分代码移至 if 子句上方，然后将其余代码移至单独的方法中，以确保这两个部分都不会执行两次。

5. 如果接收线程和 UI 线程都需要保持响应，例如进一步传入消息和用户输入，您可能需要引入第三个线程来处理消息，然后再将消息传递到 UI 线程。