问题标签 [synchronizationcontext]

一个简单的问题。这是 WinForms 应用程序的一部分：

有人可以解释为什么我看到“任务！” 首先，然后当我运行它时“退出”？

当我看到“任务！” 消息框，“退出前”已打印在调试输出中。

编辑：更简单，同样的效果：

编辑：如果我替换MessageBox.Show("Exit!")为Form { Text = "Exit!" }.ShowDialog()，我会看到“退出”，然后是“任务”，正如预期的那样。这是为什么？

我手动构建一个任务：

然后手动启动它：

我希望它通过SynchronizationContext.Post.

但如果以这种方式开始：

它是通过 执行SynchronizationContext.Send，还是直接通过调用任务的 lambda 来执行？

由于我无法控制的原因，我需要同步调用异步方法。我正在开发一个库，它使用另一个异步工作的库，我需要从Stream类的实现中使用它。此类包含同步和异步方法，我对同步的方法感到不安：

我一直在阅读如何同步运行异步 Task<T> 方法？，特别是这个答案，并且在@Stephen Cleary 的评论中指出该解决方案不好，因为某些 ASP.NET 部分需要一个AspNetSynchronizationContext. 我正在开发一个库，所以我不知道从哪里调用我的类。

同步调用异步方法的最安全方法是什么？

假设我有这个代码

当前同步上下文泄漏回线程池。如果有人再次调用 ThreadPool.QueueUserWorkItem 并且使用同一个线程来处理另一个工作项，那么该线程的当前同步上下文会被重置回 null 还是会保持 MyCustomSynchronizationContext？

相同的答案是否适用于在线程池上执行任务的任何其他方式，例如 Task.Run、BeginInvoke 等？

我知道通常 TLS 不会重置，但 .NET 源代码显示当前同步上下文的存储不是很明确定义（大部分时间它来自执行上下文，但对于某些 WinRT 来说似乎是特殊情况原因）。

我刚刚注意到，对于 .NET 4.5，每个Dispatcher.BeginInvoke/InvokeAsync回调都是在其自己非常独特的同步上下文（的实例DispatcherSynchronizationContext）上执行的。这种变化背后的原因是什么？

以下简单的 WPF 应用程序说明了这一点：

输出：

设置BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance为true恢复 .NET 4.0 行为：

研究.NET 源代码表明DispatcherOperation：

我不明白为什么可能需要这样做，无论如何排队的回调Dispatcher.BeginInvoke/InvokeAsync都在正确的线程上执行，该线程上已经DispatcherSynchronizationContext安装了一个实例。

此更改的一个有趣的副作用是.NET 4.5 WPF 中await TaskCompletionSource.Task的延续（由 触发TaskCompletionSource.SetResult）几乎总是异步的，这与 WinForms 或 v4.0 WPF 不同（更多细节）。

我有一种async方法可以用来卸载几秒钟的即发即弃的工作，以免减慢我的页面加载速度。这项工作需要一些常规设置和整理；我希望（快速）设置在抛出时同步抛出，但我不想强制整理在 ASP 上下文中运行，所以我ConfigureAwait正在等待的位上使用：

这看起来很奇怪，因为

• FireAndForgetAfterSetup不应该真正关心它是否是从 ASP 上下文中调用的，那么为什么它必须是调用者ConfigureAwait呢？
• 如果我改变主意并决定btn_Click应该等待FireAndForget完成，它是否已经丢弃了 ASP 上下文（？）

如果我有误解，有人可以向我解释吗？

据我所知，Windows 服务应用程序中没有同步上下文。

• await fooTask.ConfigureAwait(false)Windows 服务能给我带来什么好处吗 ？
• 这有什么陷阱吗？

I'm reading up on SynchronizationContext and trying to make sure I'm not messing anything up by trying to flow the OperationContext to all threads, even after an await call.

I have this SynchronizationContext class:

Which is then called like this around every method call (using a Ninject IInterceptor):

It seems to work (I'm able to use the OperationContext as needed), but is this the right way to do it? Am I missing anything important that might bite me later?

EDITed with some of Stephen Cleary's comments:

FINAL:

我的服务器中有一个异步方法，我希望始终在专用线程上运行（调用者不等待它，只是调度），而不是从 ThreadPool 中运行。我找到了一些单线程 SynchronizationContext 的实现，但它们似乎未经测试，我想使用更稳定的实现。

我找到了 Nito AsyncEx 的AsyncContext，但我无法弄清楚它是否可以在整个应用程序生命周期中在单个专用线程上运行。

有谁知道 AsyncContext 是否符合我的要求？或者，您知道单线程 SynchronizationContext 的经过测试且稳定的实现吗？

这与我之前的帖子有关，在那里我问为什么我应该在我的主 UI 表单上使用 SynchronizationContext 的 .Send 或 .Post，而不是常规的 .Invoke 或 .BeginInvoke。

我的问题是，我用于 Invoke 的委托与一个带有两个参数的方法相关联：一个字符串包含标签应更改为的实际文本，另一个字符串包含标签名称，其文本应更改.

现在的问题是 .Send 和 .Post 仅将 SendOrPostCallbake 委托作为其输入，并且该委托只能与具有单个对象作为其参数的方法相关联。由于所有东西都可以打包到一个对象中，我被建议要么创建一个类来打包我的变量（这个选项我了解如何实现），另一个是使用带有闭包的 lambda 表达式。后者我不明白该怎么做。

当我的基础方法有两个字符串参数时，关于如何在 _synch.Send() 中使用 lambda 表达式的任何指导，将不胜感激。

编辑。根据评论中的指导，我能够回答我自己的问题。为了将来的访问者的利益，我在下面发布了解决方案。