Orleans 2.0 官方文档 —— 8.4 实现细节 -> Scheduler

Scheduler

Orleans Scheduler是Orleans运行时内的一个组件，负责执行应用程序代码和部分的运行时代码，以确保单线程执行语义。它实现了一个自定义的TPL(Task Parallel Library) Task Scheduler。

Orleans Task Scheduler是一个两层级结构的调度程序。第一级是全局的OrleansTaskScheduler(OTS)，它负责执行系统活动的。在第二级，每个grain的激活体都有自己的ActivationTaskScheduler(ATS)，它提供了单线程执行语义。

在高层级上，执行路径如下：

1. 一个请求到达正确的silo，并找到目标激活体。
2. 请求被转换为一个Task，该Task在激活体的ActivationTaskScheduler上排队，等待执行。
3. 作为grain方法执行的一部分而创建的任何后续的Task，通过标准的TaskScheduler的机制，它们自然而言地排队到同一个ActivationTaskScheduler。
4. 每个ActivationTaskScheduler都有一个在等待执行的Task队列。
5. Orleans Scheduler有一组工作线程，由所有激活体的调度程序共同使用。这些线程会定期扫描所有的调度程序的队列，以执行工作。
6. 一个线程接掌一个队列（每个队列由一个线程依次接掌），并以FIFO顺序，开始执行该队列中的Task。
7. 一次接掌一个队列的线程，和该线程按顺序执行队列的Task，这两点相结合，提供了单线程执行语义。

工作项：

Orleans使用工作项的概念，来指定进入调度程序的入口点。每个新请求最初都作为一个工作项排队，此工作项简单地包装了该请求的第一个Task的执行。工作项只提供有关调度活动（调用者、活动名称、日志记录）的更多上下文信息，有时还必须代表该调度活动，完成一些额外的工作（Invoke工作项中的调用后活动）。当前有以下工作项类型：

1. Invoke工作项 —— 这是最常用的工作项类型。它表示了一个应用程序的请求的执行。
2. Request/Response工作项 —— 执行一个系统请求（对SystemTarget的请求）
3. TaskWorkItem —— 表示排队到顶层的OrleansTaskScheduler的任务。只是为了数据结构的方便而使用它，不是一个直接的任务（更多详细信息见下文）。
4. WorkItemGroup —— 共享同一调度程序的一组工作项。用于为每个ActivationTaskScheduler包装Task队列。
5. ClosureWorkItem —— 一个排队到系统上下文中的闭包（任意lambda）的包装器。

调度上下文：

调度上下文是一个标记，它只是一个表示调度目标的不透明对象 —— 激活数据、系统目标或系统null上下文。

高层级的原则：

1. 任务总是排队到正确的调度程序

   1.1任务永远不会从一个调度程序移动到另一个调度程序。

   1.2我们永远不会代表其他任务创建任务来执行它们。

   1.3 工作项包装在Task中（也就是说，为了执行工作项，我们创建一个Task，其lambda函数将只运行工作项的lambda）。通过始终执行Task，我们确保了通过适当的任务调度程序，任何活动都被执行。

2. 通过使用base.TryExecute（而不是RunSynchronously），在已排队的调度程序上执行Task。

3. ATS、WorkItemGroup和调度的上下文之间存在一对一映射：

   3.1 Activation Task Scheduler（ATS）是一个自定义的TPL调度程序。我们保持ATS精简，并将所有数据存储在WorkItemGroup中。ATS指向其WorkItemGroup。

   3.2 WorkItem Group是激活体的Task的实际持有者（数据对象）。Task存储在一个列表中 —— ATS所有任务的队列。WorkItemGroup指向其ATS。

任务、工作项的数据流和执行：

1. 入口点始终是一个排队进入OrleansTaskScheduler的工作项。它可以是Invoke/Request/Response/Closure 工作项之一。
2. 包装到一个Task中，并根据上下文，通过Task.Start排队到正确的ActivationTaskScheduler中。
3. 排队到ActivationTaskScheduler的任务被放入WorkItemGroup队列。
4. 将Task放入WorkItemGroup队列时，WorkItemGroup确保它出现在OrleansTaskScheduler全局的RunQueue中。RunQueue是那些可运行的WorkItemGroups的全局队列，它们至少有一个任务在排队，因此可以准备执行。
5. 工作线程扫描OrleansTaskScheduler的RunQueue，该队列包含WorkItemGroups并调用WorkItemGroups.Execute。

6. WorkItemGroups.Execute扫描其任务的队列，并通过ActivationTaskScheduler.RunTask(Task)，来执行它们。

   6.1 ActivationTaskScheduler.RunTask（Task）调用base.TryExecute。

   6.2通过TPL直接排队到调度程序的任务将立即执行。

   6.3包装工作项的任务将调用workItem.Execute，它将执行闭包工作项的委托。

低层级的设计 - 工作项：

1. 将工作项排队到OrleansTaskScheduler，是在Orleans运行时中，启动每个请求的整个执行链的方式。这是我们进入调度程序的入口点。

2. 工作项首先提交给OrleansTaskScheduler（因为这是提供给系统其余部分的接口）。

   2.1 只有Closure/Invoke/Resume工作项，能以这种方式提交。

   2.2 TaskWorkItem无法直接提交给OrleansTaskScheduler（请阅读下面关于TaskWorkItem的更多内容）。

3. 每个工作项都必须包装到Task中，并通过Task.Start排队到正确的调度程序。

   3.1这将确保在执行此workItem期间隐式地创建的任何Task上，正确地设置TaskScheduler.Current。

   3.2通过WrapWorkItemAsTask创建一个任务，来完成包装，该任务将执行工作项并通过Task.Start（scheduler）将其排队到正确的调度程序。

   3.3空上下文的工作项，排队到OrleansTaskScheduler。

   3.4非空上下文的工作项，排队到ActivationTaskScheduler。

低层级的设计 - 排队的任务：

1. 任务直接排队到正确的调度程序

   1.1 TPL通过protected override void QueueTask(Task task)，隐式地排队任务

   1.2具有非空上下文的Task，始终排队到ActivationTaskScheduler

   1.3具有空上下文的Task，始终排队到OrleansTaskScheduler

2. 将Task排队到ActivationTaskScheduler：

   2.1我们决不把Task包装在另一个Task中。Task直接添加到WorkItem组的队列。

3. 将Task排队到OrleansTaskScheduler：

   3.1当一个Task被排队到OrleansTaskScheduler时，我们将它包装进一个TaskWorkItem，然后放入此调度程序的工作项队列中。

   3.2这只是数据结构的事情，本质上没有什么。

   3.3 OrleansTaskScheduler通常持有工作项组来调度它们，因此它的RunQueue有一个BlockingCollection。

   3.4由于空上下文的任务也排队到OrleansTaskScheduler，我们重用相同的数据结构，因此我们必须将每个Task包装在一个TaskWorkItem中。

   3.5通过调整RunQueue数据结构，我们应该能够完全摆脱这种包装。这可能会略微简化代码，但一般来说无关紧要。此外，将来我们应该会舍弃空上下文，所以这个问题终究会消失。

内联任务：

由于任务总是排队到正确的调度程序，理论上，内联任何任务应始终是安全的。