从给定线程获取 SynchronizationContext

Question

我不知道如何获取给定 Thread 的 SynchronizationContext：

Thread uiThread = UIConfiguration.UIThread;
SynchronizationContext context = uiThread.Huh?;

为什么我需要它？

因为我需要从整个前端应用程序的不同位置发布到 UIThread。因此，我在名为 UIConfiguration 的类中定义了一个静态属性。我在 Program.Main 方法中设置了这个属性：

UIConfiguration.UIThread = Thread.CurrentThread;

在那一刻我可以确定我拥有正确的线程，但是我无法设置静态属性，

UIConfiguration.SynchronizationContext = SynchronizationContext.Current

因为该类的 WinForms 实现还没有已安装。由于每个线程都有自己的 SynchronizationContext，因此必须可以从给定的 Thread 对象中检索它，还是我完全错了？

Answer 1

这是不可能的。问题在于 SynchronizationContext 和 Thread 实际上是两个完全独立的概念。

虽然 Windows 窗体和 WPF 确实都为主线程设置了 SynchronizationContext，但大多数其他线程却没有。例如，ThreadPool 中的任何线程都不包含自己的 SynchronizationContext（当然，除非您安装自己的 SynchronizationContext）。

SynchronizationContext 也有可能与线程和线程完全无关。可以轻松设置同步上下文，以同步到外部服务或整个线程池等。

在您的情况下，我建议在初始主表单的 Loaded 中设置 UIConfiguration.SynchronizationContext事件。上下文保证在此时启动，并且在任何情况下直到消息泵启动之前都无法使用。

Answer 2

我知道这是一个老问题，并对死灵表示歉意，但我刚刚找到了这个问题的解决方案，我认为它可能对我们这些一直在谷歌搜索的人有用（并且它不需要 Control 实例）。

基本上，您可以创建 WindowsFormsSynchronizationContext 的实例，并在 Main 函数中手动设置上下文，如下所示：

    _UISyncContext = new WindowsFormsSynchronizationContext();
    SynchronizationContext.SetSynchronizationContext(_UISyncContext);

我已经在我的应用程序中完成了此操作，并且它运行完美，没有任何问题。但是，我应该指出，我的 Main 被标记为 STAThread，所以我不确定如果您的 Main 被标记，这是否仍然有效（或者是否有必要）用 MTAThread 代替。

编辑：我忘了提及它，但是 _UISyncContext 已经在我的应用程序中的 Program 类的模块级别定义。

Answer 3

我发现 Alex Davies 所著的《Async in C# 5.0. O'Reilly Publ., 2012》，第 48-49 页中的以下段落是最简洁、最有帮助的：

• "SynchronizationContext 是 .NET Framework 提供的类，它能够在特定类型的线程中运行代码< /strong>.
  .NET 使用多种同步上下文，其中最重要的是 WinForms 和 WPF 使用的 UI 线程上下文。"

• "SynchronizationContext 本身的实例不执行任何非常有用的操作，所以它的所有实际实例往往都是子类。

  它还有静态成员，可让您读取和控制当前的 SynchronizationContext。

  当前SynchronizationContext是当前线程的属性。

  这个想法是，在任何时候您在特殊线程中运行时，您都应该能够获取当前的 SynchronizationContext 并存储它。稍后，您可以使用它在您启动的特殊线程上运行代码。所有这一切都应该是可能的，不需要确切知道您在哪个线程上启动，只要您可以使用 SynchronizationContext，就可以返回它。

  SynchronizationContext的重要方法是Post，它可以使委托在正确的上下文中运行”
  。

• “某些 SynchronizationContext 封装单个线程，如 UI 线程。
  有些封装特定类型的线程 - 例如线程池 - 但可以选择其中任何线程将委托发布到。有些实际上并不会更改代码运行的线程，而仅用于监视，例如 ASP.NET 同步上下文"

Answer 4

我不相信每个线程都有自己的 SynchronizationContext - 它只是有一个线程本地的 SynchronizationContext。

为什么不在表单的 Loaded 事件中设置 UIConfiguration.UIThread 或类似的内容？

Answer 5

用于从 Thread 或 ExecutionContext 获取 SynchronizationContext 的完整且有效的扩展方法（如果不存在，则为 null） ，或来自 Dispatcher 的 DispatcherSynchronizationContext。在 .NET 4.6.2 上测试。

using Ectx = ExecutionContext;
using Sctx = SynchronizationContext;
using Dctx = DispatcherSynchronizationContext;

public static class _ext
{
    // DispatcherSynchronizationContext from Dispatcher
    public static Dctx GetSyncCtx(this Dispatcher d) => d?.Thread.GetSyncCtx() as Dctx;

    // SynchronizationContext from Thread
    public static Sctx GetSyncCtx(this Thread th) => th?.ExecutionContext?.GetSyncCtx();

    // SynchronizationContext from ExecutionContext
    public static Sctx GetSyncCtx(this Ectx x) => __get(x);

    /* ... continued below ... */
}

上述所有函数最终都会调用如下所示的 __get 代码，这需要一些解释。

请注意，__get 是一个静态字段，使用可丢弃的 lambda 块预先初始化。这使我们能够巧妙地拦截第一个调用者仅，以便运行一次性初始化，这会准备一个小型且永久的替换委托，该委托速度更快且无反射。

勇敢的初始化工作的最后一步是将替换替换为“__get”，这同时也是悲剧性地意味着代码丢弃自身，不留下任何痕迹，并且所有后续调用者直接进入 DynamicMethod 正确的状态，而无需甚至有一点旁路逻辑。

static Func<Ectx, Sctx> __get = arg =>
{
    // Hijack the first caller to do initialization...

    var fi = typeof(Ectx).GetField(
        "_syncContext",                         // private field in 'ExecutionContext'
        BindingFlags.NonPublic|BindingFlags.Instance);

    var dm = new DynamicMethod(
        "foo",                                  // (any name)
        typeof(Sctx),                           // getter return type
        new[] { typeof(Ectx) },                 // type of getter's single arg
        typeof(Ectx),                           // "owner" type
        true);                                  // allow private field access

    var il = dm.GetILGenerator();
    il.Emit(OpCodes.Ldarg_0);
    il.Emit(OpCodes.Ldfld, fi);
    il.Emit(OpCodes.Ret);

    // ...now replace ourself...
    __get = (Func<Ectx, Sctx>)dm.CreateDelegate(typeof(Func<Ectx, Sctx>));

    // oh yeah, don't forget to handle the first caller's request
    return __get(arg);                 //  ...never to come back here again. SAD!
};

最可爱的部分是最后——为了实际获取被抢占的第一个调用者的值——该函数表面上用自己的参数调用自己，但通过立即替换自己来避免递归。

没有特别的理由在本页讨论的 SynchronizationContext 特定问题上演示这种不寻常的技术。从 ExecutionContext 中获取 _syncContext 字段可以通过传统反射（加上一些扩展方法磨砂）轻松而简单地解决。但我想我应该分享这种我个人已经使用了很长一段时间的方法，因为它也很容易适应并且同样广泛适用于此类情况。

当进入非公开领域需要极限性能时尤其合适。我想我最初在基于 QPC 的频率计数器中使用了它，其中在每 20 或 25 纳秒迭代一次的紧密循环中读取字段，这对于传统反射来说实际上是不可能的。

主要答案到此结束，但下面我包含了一些有趣的观点，与提问者的询问不太相关，更多的是与刚刚演示的技术相关。

 

---

运行时调用者

为了清楚起见，我将上面显示的代码中的“安装交换”和“首次使用”步骤分成了两行，这与我自己的代码中的内容相反（以下版本也避免一次主内存获取与上一次相比，可能涉及线程安全，请参阅下面的详细讨论）：

return (__get = (Func<Ectx, Sctx>)dm.CreateDel...(...))(arg);

换句话说，所有调用者（包括第一个）以完全相同的方式获取值，并且没有使用反射代码来执行此操作。它只写入替换 getter。感谢 il-visualizer，我们可以看到该 DynamicMethod 运行时在调试器中：

无锁线程安全

我应该注意，函数体中的交换完全是考虑到 .NET 内存模型 和无锁原理的线程安全操作。后者倾向于以可能进行重复或冗余工作为代价来保证前进的进度。在完全健全的理论基础上正确允许多路竞赛初始化：

• 竞赛入口点（初始化代码）是全局预配置和保护的（由.NET加载程序），以便（多个）竞赛者（如果有）进入相同的初始值设定项，永远不会被视为 null。
• 多个种族产品（吸气剂）在逻辑上总是相同的，因此任何特定赛车手（或后来的非赛车呼叫者）碰巧拿起哪一件并不重要，甚至任何赛车手最终是否使用他们自己生产的产品都无关紧要；
• 每个安装交换都是大小为 IntPtr 的单个存储，保证对于任何相应平台位数都是原子的；
• 最后，从技术上来说，对于完美的形式正确性来说绝对至关重要，“失败者”的工作产品由 GC 回收，因此不会泄漏。在这种类型的比赛中，失败者是除了最后一位< /em> 终结者（因为其他人的努力都被愉快地、简单地覆盖为相同的结果）。

尽管我相信这些要点结合起来可以充分保护在每种可能情况下编写的代码，但如果您仍然对总体结论持怀疑或警惕态度，那么您始终可以添加额外的防弹层：

var tmp = (Func<Ectx, Sctx>)dm.CreateDelegate(typeof(Func<Ectx, Sctx>));
Thread.MemoryBarrier();
__get = tmp;
return tmp(arg);

这只是一个偏执版本。与早期的压缩单行代码一样，.NET 内存模型保证对“__get”的位置只有一次存储，以及零次提取。 （顶部的完整扩展示例确实执行了额外的主内存获取，但由于第二个要点，仍然是合理的）正如我所提到的，这些对于正确性来说都不是必需的，但从理论上讲，它可以给出一个微小的结果性能奖励：通过提前结束竞争，在极少数情况下，积极的刷新可以防止脏缓存行上的后续调用者进行不必要的（但同样是无害的）竞争。

双重 thunking

对最终超快方法的调用仍会thunked 通过前面所示的静态扩展方法。
这是因为我们还需要以某种方式表示编译时实际存在的入口点，以便编译器绑定并传播元数据。对于 IDE 中的强类型元数据和智能感知的巨大便利性来说，对于在运行时才能真正解析的自定义代码，双重 thunk 是一个很小的代价。然而，它的运行速度至少与静态编译代码一样快，方式比在每次调用时进行大量反射更快，因此我们可以两全其美！