是什麼的SynchronizationContext和的TaskScheduler

Question

Stephen Toub blogged是

雙方的SynchronizationContext和的TaskScheduler是抽象， 代表「調度」，你給一些工作的東西，它 決定何時何地之間的概念差別運行那項工作。調度器有許多不同的形式。例如，ThreadPool是一個調度程序：調用ThreadPool.QueueUserWorkItem來提供一個委託來運行， 委託隊列，並且一個ThreadPool的線程最終 接收並運行該委託。您的用戶界面還有一個調度程序：消息泵。

所以System.Reactive.Concurrency.EventLoopScheduler，Dispatcher，ThreadPool，TaskScheduler，SyncrhonizationContext和IScheduler implementations of Reactive Extensions是在這個意義上所有的 「調度」。

他們有什麼區別？

他們爲什麼都需要？我想我得到EventLoop，Dispatcher，ThreadPool。 IScheduler也很好地解釋。
但是TaskScheduler和SyncrhonizationContext仍然不清楚。

Stephen Cleary's excellent article解釋SyncrhonizationContext，我想我明白了。那麼爲什麼我們需要TaskScheduler，目前還不清楚。

請解釋或指出來源。

Answer 1

每個平臺都有自己的「調度程序」，並且它們都有自己的抽象。例如WinForms使用消息泵。 WPF使用「Dispatcher」中抽象的另一個消息泵。ThreadPool是「ThreadPool」中抽象的另一個「調度程序」。這些（和其他一些）是較低級別的調度程序。

任務和任務調度程序希望任務的用戶不必考慮在這些較低級別調度任務（當然，可以採用抽象的方式）。你應該能夠開始一個任務，並且一個環境「調度程序」應該照顧它。例如，無論我在哪個平臺下運行，TaskFactory.StartNew(()=>{LengthyOperation()})都應該可以工作。這就是SynchronizationContext進來的地方。它知道當前運行的框架涉及哪些底層調度程序。這被傳遞給TaskScheduler，並且該調度程序既可以調度任務（可能在ThreadPool上），也可以通過與當前正在運行的框架相關聯的較低級別調度程序（參見SynchronizationContext）來調度延續以保持同步要求。例如雖然您希望您的任務在ThreadPool中運行，但您可能需要繼續在UI線程中運行。

重要的是要知道TaskScheduler是多個其他調度程序的抽象。這不是它存在的唯一原因，而是這種「額外」抽象的原因之一。「

Answer 2

雖然，引，

兩者的SynchronizationContext和的TaskScheduler是抽象， 表示「調度器」

IMO，抽象度（以及因此API）不同。 SynchronizationContext是一個更通用的API，因爲Post/Send接受一個簡單的方法委託。

另一方面，TaskScheduler是特定於TPL的抽象 - 所以它提供了諸如QueueTask之類的方法，它處理Task對象。使用同步上下文而不是任務調度器（即具有TPL特定的SynchronizationContext實現）會使得使用任務調度更加繁瑣（當然，這將是TPL環境中的弱類型API）。因此，TPL設計人員選擇對抽象調度器API進行建模，這對於TPL來說是有意義的（無論如何 - 這是抽象的目的 - 對吧？） - 當然，爲了縮小差距，FCL包含內部類SynchronizationContextTaskScheduler，它是SynchronizationContext的封裝TaskScheduler實現。

SynchronizationContext是在.NET 2.0中引入的，而TPL是在.NET 4中引入的。它有趣的想法是什麼FCL設計者會選擇如果序列是其他方式，即如果TPL在.NET時期存在2.0。 IMO，TaskScheduler可以被用來代替SynchrinizationContext，通過在特定專業化中將分類建模爲任務。