SynchronizationContext和TaskScheduler之间的概念区别是什么 [英] What is the conceptual difference between SynchronizationContext and 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 ，反应式扩展程序的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之间的概念区别是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
