25、任务调度中的通信与处理器参与解析

任务调度中的通信与处理器参与解析

在并行系统的任务调度领域，通信和处理器的参与是影响调度准确性和效率的关键因素。传统的调度模型存在一些理想化的假设，在实际应用中可能无法准确反映系统的真实情况。下面我们将深入探讨通信争用和处理器参与在任务调度中的相关内容。

通信争用调度模型

传统的调度模型对于许多并行系统并不适用，因此研究出了一种更现实的系统模型。该模型摒弃了完全并发通信和全连接网络的理想化假设。在这个模型下进行任务调度时，通过将边调度到通信链路上来实现对争用的感知。由于边调度与节点调度相似，因此它既直观又强大。

分析表明，考虑争用的调度将端点争用和网络争用这两种类型的争用统一在一个模型中。这是通过扩展的网络模型及其拓扑表示来实现的。同时，网络的细节对边调度是隐藏的，边调度只关注每个通信的路由。

事实证明，只需对经典调度技术进行少量修改，就可以使其适用于考虑争用的调度。特别是，讨论了在新模型下如何采用各种形式的列表调度。

在实际应用中，几乎没有理由不选择争用模型而选择经典模型。使任务调度算法考虑争用所需的少量更改通常只会导致运行时复杂度的小幅增加。而经典模型下不同调度启发式算法之间的复杂度差异往往要大得多。此外，各种实验表明，考虑争用的调度能够显著提高准确性并缩短执行时间。

不过，考虑争用的算法实现起来更复杂。其应用还需要将目标系统建模为拓扑图。为了便于完成这项任务，可以从简单的拓扑图开始，比如星型拓扑，它对应于单端口模型，能有效地捕捉端点争用。之后，可以增强拓扑模型（即提高其准确性），以进一步改善调度结果。

然而，考虑争用的调度并不像我们期望的那样准确和高效。这表明调度模型需要进一步研究，特别是关于处理器在通信中的参与情况。

以下是几种不同系统的拓扑图建模示例：
| 系统类型 | 描述 |
| ---- | ---- |
| 由三个子网组成的PC集群 | 每个子网中有8个处理器连接到一个中央交换机，各交换机之间直接相连 |
| 9个处理节点的系统 | 通过3×3循环网格连接，每个处理节点包含一个网格接口和两个通过单总线连接的处理器 |

处理器参与通信的类型

在许多并行系统中，处理器会以某种方式参与到处理器间的通信中。处理器的参与会使通信串行化，并且更重要的是，会阻止计算和通信的重叠。因此，在任务调度中考虑处理器的参与非常重要。

处理器参与通信主要分为以下三种基本类型：
1. 双边通信 ：在双边处理器间通信中，源处理器和目标处理器都参与通信。这种情况可能出现在消息传递和共享内存架构中。在消息传递系统中，处理器的参与包括准备消息、将消息发送到网络以及从网络接收消息。在共享内存系统中，如果处理器间通信通过公共缓冲区进行，也可能是双边通信。源处理器将数据写入公共缓冲区，目标处理器从那里读取数据。
2. 单边通信 ：如果只有两个参与处理器中的一个参与通信，则称为单边通信。这种类型的通信仅限于共享内存系统，即源处理器将数据写入目标位置（共享内存“put”）或目标处理器从源位置读取数据（共享内存“get”）。对于单边通信，执行通信的活动处理器必须能够直接访问数据位置。
3. 第三方通信 ：在第三方处理器间通信中，数据传输由专用的通信设备完成。这些通信设备必须能够直接访问本地和远程内存，而无需处理器的参与。处理器只需告知通信设备要传输的内存区域，其余的通信工作由设备完成。因此，处理器的通信开销大约是恒定的，与要传输的数据量无关。

任务调度在经典模型和争用模型下都假设是第三方类型的处理器间通信。因此，生成的调度会使计算与通信重叠。然而，这种重叠只存在于具有专用通信子系统的系统中。在执行单边或双边通信的其他系统中，生成的调度是不现实的，因此是不合适的。

以下是三种通信类型的对比表格：
| 通信类型 | 处理器参与情况 | 适用系统 | 示例 |
| ---- | ---- | ---- | ---- |
| 双边通信 | 源和目标处理器都参与 | 消息传递和共享内存架构 | PC集群的TCP/IP通信、SGI Origin 2000的MPI实现 |
| 单边通信 | 只有一个处理器参与 | 共享内存系统 | Cray T3E的远程内存访问 |
| 第三方通信 | 处理器不参与，由专用设备完成 | 具有专用通信子系统的系统 | Meiko CS - 2、IBM SP - 2 |

处理器参与通信的特征

为了更精确地描述处理器的参与情况，可以将其分解为开销和直接参与两部分。

• 开销 ：处理器参与通信的第一个组成部分是通信设置或开销。从通信过程启动到第一个数据项被放到网络上，处理器都在为通信做准备。通常，在数据到达后，目标处理器在能够使用接收到的数据之前也会产生开销。开销主要包括通过通信层的过程，因此随着通信环境抽象级别的提高而增大。典型的任务包括数据的打包和解包、缓冲、格式转换、错误控制等。通信硬件也可能会为控制通信设备带来开销，特别是在第三方通信中。需要注意的是，同一处理器上执行的任务之间的通信不会产生开销。开销的重要性取决于任务图的粒度，对于细粒度任务，开销可能会对程序执行产生重大影响。
• 直接参与 ：在处理器完成通信准备的开销之后，任何进一步参与通信的行为都是直接参与。其特点是数据已经在通信网络中传输。直接参与从数据在网络上开始传输时开始，直到最后一个数据字的存储命令执行完毕才结束。如果数据量较小，处理器参与的时间与开销相比会很短，特别是当只传输一个数据项时。

不同通信类型的开销和直接参与的长度有所不同：
- 开销 ：通常在两个处理器上的时间是恒定的，尽管长度可能不同。开销主要是由于通过通信层的过程，对于不同的数据传输，这个过程不会有太大变化。也就是说，开销通常与数据大小无关。但在某些环境中，数据可能会被复制到缓冲区和从缓冲区复制出来，这当然是一个与数据大小成比例的操作。
- 直接参与 ：直接参与的长度主要由通信类型决定。在逻辑上，某些处理器的直接参与时间为零，例如在第三方通信中两个处理器的直接参与时间都为零，在单边通信中，发送或接收处理器中的一个的直接参与时间为零。

对于基于数据包的通信，开销和直接参与的清晰分离并不那么明显。例如，在双边处理器间的数据包通信中，发送处理器在通信开始时会经历通信层，这表现为开销。如果数据最多只有一个数据包的大小，它会被复制到网络适配器，然后适配器将消息发送到目的地。这种行为可以用开销和直接参与的概念很好地捕捉。然而，长消息必须拆分成多个数据包。在每个数据包在网络上传输时，处理器不参与，可以继续进行计算。但在传输完前一个数据包后，处理器在提交下一个数据包到适配器时会经历新的、较小的开销和直接参与。接收处理器在接收和组装数据包时也会有类似的情况。

可以用单个开销和单个直接参与来近似基于数据包的通信。将所有数据包的各种开销和直接参与统一为一个开销和一个直接参与。需要注意的是，单个开销只对应于数据包视图中的初始开销，小的增量开销被计入直接参与中，因为这些开销与网络活动同时发生，因此可以被视为直接参与。

以下是开销和直接参与在不同通信类型中的示例图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(双边通信):::process --> B(开销):::process
    A --> C(直接参与):::process
    D(单边通信):::process --> E(开销):::process
    D --> F(直接参与):::process
    G(第三方通信):::process --> H(开销):::process
    G --> I(无直接参与):::process

综上所述，开销和直接参与的概念非常灵活，它们允许对所有三种类型的处理器间通信进行统一描述，即使处理器的参与只是部分的。同时，它们直观易懂，并且能够轻松地与边调度集成。这些概念将在考虑处理器参与通信的任务调度策略中得到应用。

任务调度中的通信与处理器参与解析

处理器参与对调度的影响及新模型的提出

在任务调度中，经典模型和争用模型都假设是第三方类型的处理器间通信，这使得生成的调度会让计算与通信重叠。但实际上，很多系统进行的是单边或双边通信，这些系统上的调度会因这种假设而变得不现实，从而导致准确性和执行时间受到负面影响。

处理器参与通信会带来两个重要影响：一是使通信串行化，二是阻止计算和通信的重叠。因为处理器在同一时间通常只能处理一个通信，比如一次只能进行一个内存复制操作。这就意味着，在调度时如果不考虑处理器的参与，可能会得到无法在实际系统中有效执行的调度方案。

为了解决这个问题，需要一个新的调度模型，该模型要基于争用模型并考虑处理器的参与。这个新模型更加通用，它能够统一其他调度模型。在新模型下进行调度，需要对现有的调度技术进行调整。

以下是不同模型下调度的特点对比：
| 模型类型 | 通信假设 | 计算与通信重叠情况 | 实际系统适用性 |
| ---- | ---- | ---- | ---- |
| 经典模型 | 第三方通信 | 可重叠 | 仅适用于有专用通信子系统的系统 |
| 争用模型 | 第三方通信 | 可重叠 | 部分情况下不准确，需改进 |
| 新模型（考虑处理器参与） | 考虑多种通信类型 | 需根据实际情况判断 | 更广泛适用于各类并行系统 |

新模型下的调度技术调整

在新模型下，主要讨论了对列表调度和简单遗传算法启发式方法的调整。

列表调度

列表调度是一种常见的调度方法，在新模型下，需要对其进行修改以适应处理器参与的情况。具体来说，在调度过程中要考虑处理器的通信开销和直接参与时间。例如，当一个任务需要进行通信时，要根据处理器的当前状态（是否正在处理其他通信）来确定该任务的开始时间。如果处理器正在参与其他通信，那么该任务的通信操作需要等待，直到处理器空闲。

以下是列表调度在新模型下的简单流程：
1. 对任务进行排序（如按某种优先级顺序）。
2. 依次取出任务：
- 检查任务的通信需求。
- 查找可用的处理器，考虑处理器的通信状态。
- 如果处理器空闲，根据通信开销和直接参与时间安排任务开始时间。
- 如果处理器正在参与通信，将任务放入等待队列。
3. 当处理器完成当前通信后，从等待队列中取出合适的任务继续调度。

graph TD
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(任务排序):::process --> B(依次取任务):::process
    B --> C{检查通信需求}:::process
    C -->|有通信需求| D{查找可用处理器}:::process
    D -->|处理器空闲| E(安排任务开始时间):::process
    D -->|处理器忙| F(放入等待队列):::process
    E --> B
    F --> G{处理器空闲?}:::process
    G -->|是| H(从等待队列取任务):::process
    H --> B
    C -->|无通信需求| E

简单遗传算法启发式方法

遗传算法是一种基于生物进化原理的优化算法。在新模型下使用简单遗传算法启发式方法进行调度时，要将处理器参与通信的因素融入到适应度函数中。适应度函数用于评估每个调度方案的优劣，在考虑处理器参与后，适应度函数要综合考虑任务的执行时间、通信时间以及处理器的空闲时间等因素。

以下是简单遗传算法启发式调度的大致步骤：
1. 初始化种群，生成一组随机的调度方案。
2. 计算每个调度方案的适应度值，考虑处理器参与通信的情况。
3. 根据适应度值选择优秀的调度方案进行交叉和变异操作，生成新的种群。
4. 重复步骤2和3，直到满足终止条件（如达到最大迭代次数）。
5. 选择适应度值最优的调度方案作为最终结果。

实验验证与结论

通过实验验证了新模型的有效性。实验结果表明，考虑处理器参与的调度模型能够显著提高调度的准确性，并且缩短执行时间。与经典模型和争用模型相比，新模型更能反映实际系统的情况，尤其是在通信量较大的情况下，优势更加明显。

然而，新模型也并非完美。它的实现相对复杂，需要更详细地了解系统的通信特性和处理器的行为。在实际应用中，可能需要根据具体系统进行进一步的优化和调整。

未来，随着并行系统的不断发展，处理器参与通信的问题可能会更加复杂。需要继续研究和改进调度模型，以适应新的硬件架构和应用需求。同时，如何更高效地实现考虑处理器参与的调度算法，也是一个值得深入探讨的问题。

总之，在任务调度中考虑处理器参与通信是非常必要的，新模型为解决这一问题提供了一个有效的途径。通过不断的研究和实践，有望进一步提高并行系统的任务调度效率和性能。