wpf - 缓存 TaskScheduler 在 WPF 应用程序中检索 FromCurrentSynchronizationContext

Question

在加载 WPF 应用程序时存储/缓存从 TaskScheduler.FromCurrentSynchronizationContext 返回的 TaskScheduler 并从那里开始使用它是否有意义？这种用法有什么缺点吗？

我从缓存中的意思是在单例中存储对 TaskScheduler 的引用，并使其可用于我的应用程序的所有部分，可能是在 DI/IoC 容器的帮助下，或者在最坏的情况下是裸单例。

Answer 1

正如德鲁所说，这样做没有性能优势。但可能还有其他原因可以坚持 TaskScheduler .

您可能想要这样做的一个原因是，当您需要 TaskScheduler 时打电话可能来不及FromCurrentSynchronizationContext因为您可能不再能够确定自己处于正确的环境中。 (例如，也许您可​​以保证您的构造函数在正确的上下文中运行，但是您无法保证您的类的任何其他方法何时被调用。)

唯一的途径就是获得TaskScheduler对于 SynchronizationContext是通过FromCurrentSynchronizationContext方法，您需要存储对 TaskScheduler 的引用本身，而不仅仅是抓取 SynchronizationContext.Current在您的构造函数期间。但我可能会避免称其为“缓存”，因为这个词暗示您是出于性能原因而这样做的，而实际上您是出于必要而这样做的。

另一种可能性是您的代码可能不知道哪个特定 TaskScheduler它正在使用，但仍需要使用调度程序，因为它会触发新任务。 (如果您开始新任务，即使您没有意识到，您也在选择调度程序。如果您没有明确选择要使用的调度程序，您将使用默认的调度程序，这并不总是正确的去做。)我写了代码，在这种情况下:我写了接受 TaskScheduler 的方法。 object 作为参数并将使用它。因此，这是您可能希望保留对调度程序的引用的另一种情况。 (我使用它是因为我希望某些 IO 操作发生在特定线程上，所以我使用了自定义调度程序。)

话虽如此，应用范围的单例对我来说听起来并不是一个好主意，因为它往往会使测试变得更加困难。并且这也意味着获取共享调度程序的代码正在假设它应该使用哪个调度程序，这可能是代码异味。