SynchronizationContext和TaskScheduler之间的概念区别是什么

SynchronizationContext和TaskScheduler都是抽象的 代表一个调度程序"，您要做一些工作， 确定何时何地运行该工作.有很多不同 调度程序的形式.例如，ThreadPool是一个调度程序:您 调用ThreadPool.QueueUserWorkItem以提供要运行的委托， 委托排队，最终ThreadPool的线程之一 接起并运行该委托.您的用户界面还具有一个 调度程序:消息泵. Both SynchronizationContext and TaskScheduler are abstractions that represent a "scheduler", something that you give some work to, and it determines when and where to run that work. There are many different forms of schedulers. For example, the ThreadPool is a scheduler: you call ThreadPool.QueueUserWorkItem to supply a delegate to run, that delegate gets queued, and one of the ThreadPool’s threads eventually picks up and runs that delegate. Your user interface also has a scheduler: the message pump.因此 System.Reactive.Concurrency.EventLoopScheduler ， Dispatcher ， ThreadPool ， TaskScheduler ， SyncrhonizationContext 和反应式扩展程序的IScheduler实现都是这种意义上的调度程序".So System.Reactive.Concurrency.EventLoopScheduler, Dispatcher, ThreadPool, TaskScheduler, SyncrhonizationContext, and IScheduler implementations of Reactive Extensions are all "schedulers" in that sense.它们之间有什么区别?What is the difference between them?为什么它们都是必需的?我想我得到了EventLoop，Dispatcher，ThreadPool. IScheduler也有很好的解释.但是TaskScheduler和SyncrhonizationContext仍然不清楚.Why were they all necessary? I think I get EventLoop, Dispatcher, ThreadPool. IScheduler are also well explained.But TaskScheduler and SyncrhonizationContext still not clear to me. Stephen Cleary的精彩文章解释了SyncrhonizationContext，我认为它.为什么然后我们需要TaskScheduler，还不清楚.Stephen Cleary's excellent article explains SyncrhonizationContext, and I think I get it. Why then we needed TaskScheduler, is not clear.请解释或指向消息来源.Please explain or point to a source.推荐答案每个平台都有自己的调度程序"，并且它们周围都有自己的抽象.例如WinForms使用消息泵. WPF使用另一个在分派器"中抽象的消息泵. ThreadPool是在"ThreadPool"中抽象的另一个调度程序".这些(以及其他一些)是较低级别的调度程序.Each platform has it's own "scheduler" and they have their own abstractions around them. e.g. WinForms uses a message pump. WPF uses another message pump abstracted within "Dispatcher". A ThreadPool is another "scheduler" abstracted within "ThreadPool". These (and some others) are lower-level schedulers.任务和TaskScheduler希望Task的用户不必考虑在这些较低级别进行任务调度(当然，您可以抽象地安排任务).您应该能够启动任务，并且周围的调度程序"应该照顾好它.例如，无论我在什么平台上运行，TaskFactory.StartNew(()=>{LengthyOperation()})都应该可以工作.这就是SynchronizationContext的来源.它知道当前正在运行的框架中涉及哪些较低级别的调度程序.将其传递给TaskScheduler，并且该调度程序既可以调度任务(可能在ThreadPool上)，又可以通过与当前运行的框架相关联的下级调度程序(请参见SynchronizationContext)调度连续性，以维护同步要求.例如尽管您希望Task在ThreadPool中运行，但您可能希望继续在UI线程中运行.A Task and a TaskScheduler would like the user of a Task to not have to think about scheduling tasks at these lower levels (you can of course, in an abstracted way). You should be able to start a task and an ambient "scheduler" should take care of it. For example, TaskFactory.StartNew(()=>{LengthyOperation()}) should work regardless of what platform I'm running under. That's where a SynchronizationContext comes in. It knows about what lower-level schedulers are involved in the currently running framework. That is passed along to a TaskScheduler and that scheduler can both schedule tasks (possibly on to the ThreadPool) and schedule continuations through the lower-level scheduler associated with the currently running framework (see SynchronizationContext) to maintain synchronization requirements. e.g. although you'd like your Task to run in the ThreadPool, you may want a continuation to run in the UI thread.重要的是要知道TaskScheduler是多个其他调度程序的抽象.这不是它存在的唯一原因，而是这种额外"抽象的原因之一.It's important to know that the TaskScheduler is a abstraction of multiple other schedulers. This isn't the only reason it exists, but one of the reasons for this "extra" abstraction". 这篇关于SynchronizationContext和TaskScheduler之间的概念区别是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！