问题标签 [synchronizationcontext]

由于另一个帖子（请参阅：使用来自其他线程的 WPF Extended Toolkit MessageBox 和奇怪的行为），我对 WPF 中辅助 GUI（它们自己的线程上的 GUI）中的 Dispatcher、TaskScheduler、SynchronizationContext 的作用和使用感到非常困惑。我可以在不同的线程上创建另一个 GUI 窗口。请参阅我引用的 stackoverflow 帖子或http://reedcopsey.com/2011/11/28/launching-a-wpf-window-in-a-separate-thread-part-1/讨论您可能想要的方式/原因去做这个。但是，我只是在使用 MainWindow 调度程序、SynchronizationContext 和 TaskScheduler。具体来说，在我的新 GUI 的 threadproc 中，我只有：

当我尝试在第二个线程上的新 GUI 中创建 TaskScheduler 时，事情没有奏效。
单独线程上的 GUI 不应该有自己的 Dispatcher 和 TaskScheduler 吗？

我已经搜索过此信息，但无济于事。我不能说我的做法有问题。一切都很好。但我想了解发生了什么。具体来说： 1. UI TaskScheduler 真的只有 1 个吗？2. 只有 1 个 UI Dispatcher？3. 有人可以解释（或提供链接） Dispatcher、TaskScheduler 和 SynchronizationContext 之间的联系吗？

谢谢，

戴夫

在异步函数内部使用与外部不同的 SynchronizationContext 时，我的行为令人困惑。

我的大部分程序代码使用自定义 SynchronizationContext，它只是将 SendOrPostCallbacks 排队并在我的主线程中的特定已知点调用它们。我在开始时设置了这个自定义 SynchronizationContext，当我只使用这个时一切正常。

我遇到的问题是我有一些函数，我希望它们的等待继续在线程池中运行。

我得到的行为是每次等待之后的代码都是在看似随机的线程中执行的。有时，WeShouldBeInTheMainThreadNow() 在线程池线程中运行，有时在主线程中运行。有时 WeShouldBeInAThreadPoolThread() 正在运行

我在这里看不到任何模式，但我认为无论 SynchronizationContext.Current 在您使用 await 的行设置为什么，都将定义 await 之后的代码将在何处执行。这是一个不正确的假设吗？如果是这样，是否有一种紧凑的方式来做我在这里想做的事情？

我正在使用带有SynchronizationContext对象的回调来从 WCF 服务更新客户端 UI。

我使用的代码模式如下：

该Post方法接受一个委托和一个状态对象。没有其他签名。

因为我使用的是匿名方法，所以我倾向于写：

因为：

• 它更短
• 它节省了演员表
• 无需声明局部变量

虽然它有效，但我想知道第二种方法可能涉及哪些风险。

这被认为是安全的吗？结果参数会被后续调用以某种方式“损坏”吗？

WinRT CoreDispatcher 具有 RunAsync 方法，该方法实际上不采用状态变量。

翻译：在最常见的情况下，通过发布到 Dispatcher 发生的每个通知最终都会由于关闭而在内部分配。忽略了一个简单而重要的设计，这非常令人担忧。

例如：实现 INotifyPropertyChanged 的​​一个简单的常见示例需要一个最终结果如下的方法：

现在，每次调用一个简单的 prop changed 通知时，编译器都会在后台分配一个新的类，这对于很多通知来说是可怕的。这使得回退到 SynchronizationContext.Post，这是一个更有效的选择，当有很多通知时，考虑到它有一个状态变量，处理程序和 propertyName 可以一起传递。

任何关于如何在这种情况下使用 Dispatcher 的建议或想法将不胜感激。

我正在努力了解SynchronizationContext和朋友。如果我在例如控制台应用程序的开头设置自定义同步上下文。在什么情况下，当前同步上下文将与我的异步操作一起流动？和其他人之间是否存在差异Task，例如Delegate.BeginInvoke？

如果我在线程池上执行东西，我是否被迫将同步上下文分配给当前正在执行我的工作的特定线程？

考虑下面的 windows 窗体代码：

这里在第 3 行抛出异常，因为在 await 之后代码是在非 UI 线程上执行的。ConfigureAwait(false) 在哪里有用？

我有依赖SynchronizationContext（由应用程序提供）的库代码来序列化一些操作并在同一个线程上执行它们。此库代码与将在其中运行的应用程序无关。

但是，只有一些实现SynchronizationContext会这样做，比如WindowsFormSynchronizationContext，DispatcherSynchronizationContext可能还有其他我不知道的实现。

其他实现，如基础SynchronizationContext本身，AspNetSynchronizationContext是自由线程的；他们不会对操作进行序列化。

如果我的代码得到 a SynchronizationContext，它如何区分这两种情况？如果同步上下文不合适，我希望它快速失败并出现明显错误。

我有使用经典 MVVM 模式实现的 WPF 应用程序，但是 View、Model 和 ViewModel 是我的解决方案中的三个不同项目。

我的ViewModel 中有众所周知的AsyncObservebleCollection实现

bq.QueueTask(this.ExecuteCommand) -> backgroundWorker 正在后台线程上执行命令，它更新了我的视图中的 Messages 属性。

现在，我收到线程冲突异常，因为 AsyncObservebleCollection 没有 UI 的 SynchronizationContext，而且我知道 ViewModel 不应该知道 View，我该如何解决我的问题？如何使用 UI 的 SynchronizationContext 异步运行 RelayCommand 并更新 UI？

谢谢

我有一个自定义框架，其中主机应用程序运行事件循环并将来宾应用程序加载到单独的应用程序域中。来宾应用程序可以通过提供的 API 来利用事件循环。我想让来宾应用程序能够自动将所有延续传播到事件循环中，就像在 .NET GUI 应用程序和 UI 线程中所做的那样。因此，我创建了一个能够做到这一点的自定义同步上下文。

但问题是我无法开始使用这个新的上下文。每当我尝试设置它时，它都会null在跨应用程序域边界的下一个回调中重置。

这里有一个快速的代码片段来说明这个问题：

输出：

SynchronizationContext.SetThreadStaticContext如果它在桌面上可用，还有一种方法可以潜在地解决上述问题。

当然，总有一种方法可以在执行任何其他工作之前在每个回调中显式设置上下文。但这似乎有点糟糕。除此之外，我看不到解决这个鸡蛋问题的优雅方法。顺便说一句，它在 Mono 上按预期工作。

根据这篇文章 ASP.NET 要求在控制器中使用相同SynchronizationContext的异步操作，否则它会阻塞正在运行的线程。作为结论，作者提到我们应该使用这两种方法作为防止线程死锁的最佳实践：

1. 在您的“库”异步方法中，尽可能使用 ConfigureAwait(false)。

2. 不要阻塞任务；一直使用异步。

   注意：最好同时应用这两种最佳实践。任何一种都可以防止死锁，但必须同时应用这两种方法以实现最大的性能和响应能力。

但是是什么目的导致微软使用相同的SynchronizationContext呢？可能使用ConfigureAwait(false)禁用相同同步上下文限制的 ，可能会导致不可预知的行为或性能问题。因此，在任何可能的地方使用 真的是一种好习惯ConfigureAwait(false)吗？