sự khác biệt về khái niệm giữa SynchronizationContext và TaskScheduler

Question

Stephen Toub blogged rằng

Cả SynchronizationContext và TaskScheduler là trừu tượng mà đại diện cho một “lịch trình”, một cái gì đó mà bạn cung cấp cho một số công việc, và nó xác định khi nào và ở đâu là gì chạy công việc đó. Có nhiều hình thức khác nhau của các bộ lập lịch biểu. Ví dụ, ThreadPool là một scheduler: bạn gọi ThreadPool.QueueUserWorkItem để cung cấp cho một đại biểu để chạy, rằng đại biểu được xếp hàng đợi, và một trong các chủ đề của ThreadPool cuối cùng chọn và chạy đại biểu đó. Giao diện người dùng của bạn cũng có một bộ lập lịch : bơm thông báo.

Vì vậy System.Reactive.Concurrency.EventLoopScheduler, Dispatcher, ThreadPool, TaskScheduler, SyncrhonizationContext, và IScheduler implementations of Reactive Extensions là tất cả "schedulers" trong ý nghĩa đó.

Sự khác nhau giữa chúng là gì?

Tại sao tất cả đều cần thiết? Tôi nghĩ rằng tôi nhận EventLoop, Dispatcher, ThreadPool. IScheduler cũng được giải thích.
Nhưng TaskScheduler và SyncrhonizationContext vẫn chưa rõ ràng với tôi.

Stephen Cleary's excellent article giải thích SyncrhonizationContext, và tôi nghĩ mình đã hiểu. Tại sao chúng ta cần TaskScheduler, không rõ ràng.

Vui lòng giải thích hoặc trỏ đến nguồn.

Answer 1

Mỗi nền tảng có "bộ lập lịch biểu" riêng và chúng có phần trừu tượng riêng của chúng xung quanh. ví dụ. WinForms sử dụng một máy bơm tin nhắn. WPF sử dụng một máy bơm tin nhắn trừu tượng trong "Dispatcher".Một ThreadPool là một "scheduler" trừu tượng trong "ThreadPool". Những (và một số khác) là các trình lên lịch cấp thấp hơn.

Nhiệm vụ và TaskScheduler muốn người dùng Tác vụ không phải suy nghĩ về việc lập kế hoạch nhiệm vụ ở các cấp thấp hơn này (bạn có thể tất nhiên, theo cách trừu tượng). Bạn sẽ có thể bắt đầu một nhiệm vụ và một "bộ lập lịch" xung quanh nên chăm sóc nó. Ví dụ: TaskFactory.StartNew(()=>{LengthyOperation()}) sẽ hoạt động bất kể nền tảng nào tôi đang chạy. Đó là nơi một số SynchronizationContext xuất hiện. Nó biết về những gì mà các trình lên lịch cấp thấp hơn có liên quan đến khung công tác hiện đang chạy. Điều đó được chuyển đến một số TaskScheduler và lịch biểu đó có thể lên lịch các nhiệm vụ (có thể trên ThreadPool) và lên lịch tiếp tục thông qua bộ lập lịch mức thấp hơn được kết hợp với khung hiện đang chạy (xem SynchronizationContext) để duy trì các yêu cầu đồng bộ hóa. ví dụ. mặc dù bạn muốn Nhiệm vụ của mình chạy trong ThreadPool, bạn có thể muốn tiếp tục chạy trong chuỗi giao diện người dùng.

Điều quan trọng cần biết là TaskScheduler là sự trừu tượng hóa của nhiều trình lập lịch khác. Đây không phải là lý do duy nhất nó tồn tại, nhưng một trong những lý do cho sự trừu tượng "thêm" này ".

Answer 2

Mặc dù, như trích dẫn,

Cả SynchronizationContext và TaskScheduler là trừu tượng mà đại diện cho một “lịch trình”

IMO, mức độ trừu tượng (và do đó API) khác. SynchronizationContext là một API tổng quát hơn theo nghĩa là Post/Send có một phương thức delegate đơn giản.

Mặt khác, TaskScheduler là một trừu tượng dành riêng cho TPL - do đó, nó cung cấp các phương thức như QueueTask giao dịch với đối tượng Task. Sử dụng bối cảnh đồng bộ hóa thay vì task scheduler (tức là có một thực thi TPL cụ thể của SynchronizationContext) sẽ làm cho nó tẻ nhạt hơn khi làm việc với task scheduling (và dĩ nhiên, nó sẽ là một API được đánh máy yếu trong ngữ cảnh TPL). Vì vậy, các nhà thiết kế TPL đã chọn để mô hình hóa một API lập lịch trừu tượng có ý nghĩa cho TPL (đó là mục đích trừu tượng - phải không?) - tất nhiên, để thu hẹp khoảng cách, FCL chứa một lớp nội bộ SynchronizationContextTaskScheduler đó là trình bao bọc TaskScheduler trên SynchronizationContext.

Đồng bộ hóa Nội dung được giới thiệu trong .NET 2.0 trong khi TPL được giới thiệu trong .NET 4. Thật thú vị khi nghĩ rằng những gì nhà thiết kế FCL đã chọn nếu trình tự theo cách khác vòng tức là nếu TPL đã tồn tại tại thời điểm .NET. 2.0. IMO, TaskScheduler có thể đã được sử dụng thay vì SynchrinizationContext bằng cách mô hình hóa delgates như là nhiệm vụ trong chuyên môn cụ thể.