原文地址：devblogs.microsoft.com/oldnewthing…
原文作者：devblogs.microsoft.com/oldnewthing…
发布时间：2020年4月8日
我们一直在研究非敏捷委托的一种特殊情况，即在后台线程上调用委托，并希望在UI线程上同步执行。那么其他情况呢？
对，那它们呢？我们写出一个表来。
| 处理在\发起于 | 后台线程 | UI线程 |
|---|---|---|
| 后台线程 | 已经有了 | 没有意义 |
| UI线程 | resume_synchronous | 已经有了 |
| 其他UI线程 | resume_synchronous | resume_synchronous |
其中有两个箱子上标着已经有了。这些情况是指事件是在你想处理的同一个公寓中提出的，在这种情况下，一切都很好，没有必要玩什么公寓切换游戏。
其中有两个盒子的标签是 resume_synchronous。在这些情况下，你想在一个UI线程上同步运行处理程序，而这个线程不是你的处理程序被调用的线程。在这些情况下，你可以使用我们上次讨论的 resume_synchronous 函数。当然，由于你是在一个UI线程上运行，你不应该执行长时间的阻塞操作。如果你在右下角，这一点尤其正确，因为当你的事件处理程序运行时，你要挟两个UI线程。
这就剩下最后一个方框了，标注为Makes no sense。
这个框是没有意义的。
这个方框代表了这样一种情况：事件是在一个UI线程上引发的，但你想在一个后台线程上同步处理它。为什么要这样做呢？
通常移到后台线程的原因是为了让你在不影响UI线程响应速度的情况下执行长期运行的操作。但这在这里对我们没有帮助，因为这个表是要在另一个公寓里同步运行代码，所以在后台线程工作的时候，UI线程要保持无响应。切换到后台线程也没有任何作用。你还不如直接在UI线程上做。
请记住，整个讨论是在同步运行处理程序的情况下进行的。如果你可以异步运行处理程序，或许是在延迟的协助下，那么你就应该这样做。
下一次我们将以不同的方式将这个讨论与C++/WinRT联系起来，从而结束这个讨论。
通过www.DeepL.com/Translator （免费版）翻译
