1. 项目概述：华为OD机试中的GPU调度挑战

最近在技术社区和求职圈里，华为OD（Outsourcing Development）的机试题目热度一直不减，尤其是涉及到系统底层和性能优化的题目。其中，“GPU调度问题”算是一个经典且有一定难度的考察点。它不仅仅是让你写个算法，更是对你多线程/进程编程、资源管理、以及对计算硬件（特别是GPU）工作方式理解深度的一次综合检验。很多朋友在初次接触时，会觉得无从下手，因为学校课程里很少会如此具体地将算法和硬件调度结合起来。

简单来说，这个问题的核心是模拟一个简化的GPU任务调度器。想象一下，你有一个计算能力强大的GPU，但同时有一堆计算任务（比如深度学习模型的层、图形渲染指令）排队等着用它。这些任务有各自的优先级、计算耗时（时间片）和依赖关系（比如任务B必须等任务A完成后才能开始）。你的目标就是设计一个调度策略，高效、公平地安排这些任务在GPU上执行，并输出最终的调度顺序和总完成时间。在机试场景下，通常会要求你处理任务队列、实现调度算法（如优先级调度、时间片轮转等），并处理可能的任务依赖（拓扑排序）。

为什么用C++、Java这些语言来解？因为这类问题天然适合考察系统级编程能力。C++/C让你贴近硬件，手动管理内存和线程；Java以其强大的并发包（java.util.concurrent）展示清晰的抽象；Python则胜在快速原型和表达清晰；JavaScript（Node.js）在非阻塞I/O和事件循环模型上提供了另一种并发视角。面试官通过你选择的语言和实现，能清晰看到你对并发模型、数据结构和算法效率的权衡能力。

2. 核心需求与场景拆解

要解决这个问题，我们首先得把题目描述“翻译”成程序员能理解的具体需求和约束条件。根据常见的华为OD机试题风格，我们可以拆解出以下几个核心模块。

2.1 输入数据建模

题目通常会给出一个任务列表。每个任务至少包含以下几个属性：

• 任务ID：唯一标识符。
• 优先级：一个整数，数值越大可能表示优先级越高（或越低，需明确）。
• 执行时间：该任务需要占用GPU的计算时间（单位通常是虚拟的“时间单位”）。
• 依赖任务ID列表：一个数组，列出了该任务开始前必须已经完成的任务ID。这引入了“有向无环图”的拓扑结构。

输入可能来自标准输入（stdin）或函数参数，格式可能是第一行是任务数量N，后面N行每行描述一个任务，例如：任务ID 优先级 执行时间 依赖任务ID1 依赖任务ID2 ...。

数据结构选择：我们需要一个高效的方式来存储和查询任务。一个Task类（或结构体）是必不可少的。在内存中，我们通常用邻接表或类似结构来表示依赖图。例如，为每个任务维护一个“入度”（有多少前置任务未完成）和一个“后继任务列表”。

2.2 调度算法实现

这是问题的核心。常见的调度策略包括：

1. 基于优先级的调度：总是选择当前可执行任务中优先级最高的任务投入运行。这需要维护一个优先队列（堆）。
2. 时间片轮转：每个任务执行一个固定的短时间片，然后被放回就绪队列末尾，适用于所有任务优先级平等的场景。
3. 混合策略：在华为OD的题目中，更可能是带有依赖关系的优先级调度。即，只有入度为0的任务（没有未完成的前置任务）才具备被调度的资格，然后在这些就绪任务中，根据优先级选择。

关键点：调度器需要在一个模拟的时间线上推进。我们维护一个当前时间currentTime和一个事件队列（通常是优先队列，按任务完成时间排序）。当一个任务完成时，我们将其从GPU上释放，更新当前时间到该任务完成时刻，然后检查是否有新的任务因为此任务完成而变为就绪状态（入度减为0），并将其加入就绪队列。接着，如果GPU空闲，就从就绪队列中取出最高优先级的任务开始执行，并计算其完成时间，作为一个新的事件加入事件队列。

2.3 输出结果规范

最终输出通常需要两部分：

1. 任务执行序列：按照任务开始执行的顺序输出任务ID。这反映了调度器的决策顺序。
2. 总完成时间：所有任务都执行完毕时的currentTime，即整个作业流的完成时间。

输出格式需要严格遵循题目要求，例如每行一个任务ID，最后一行输出总时间。

2.4 边界条件与异常处理

机试题目非常注重鲁棒性。我们需要考虑：

• 循环依赖检测：如果任务依赖关系图中存在环，则调度无法进行。需要在初始化阶段通过拓扑排序进行检测。
• 空输入或单个任务。
• 优先级相同的情况：需要定义次级排序规则，例如按任务ID升序。
• 大任务量下的性能：任务数N可能达到10^5级别，算法复杂度需控制在O(N log N)级别，这就要求我们使用堆（优先队列）而非线性查找。

3. 多语言解决方案设计与对比

选择不同的编程语言，意味着选择了不同的并发原语、数据结构和编程范式。下面我们分别看看用C++、Java、JavaScript、Python和C语言解决此问题的典型思路和关键代码片段。

3.1 C++解决方案：追求极致性能与控制力

C++方案的核心在于精细的内存管理和高效的数据结构。我们使用标准模板库。

关键数据结构：

#include <iostream> #include <vector> #include <queue> #include <unordered_map> using namespace std; struct Task { int id; int priority; int duration; // 执行时间 int inDegree; // 入度 vector<int> nextTasks; // 后继任务列表 }; class GPUScheduler { private: unordered_map<int, Task> tasks; // 就绪队列：最大堆，按优先级比较。pair<优先级, 任务ID>， 优先级相同则比较ID priority_queue<pair<int, int>> readyQueue; // 事件队列：最小堆，按完成时间排序。pair<完成时间, 任务ID> priority_queue<pair<int, int>, vector<pair<int, int>>, greater<>> eventQueue; int totalTime = 0; vector<int> executionOrder;

调度核心循环：

void schedule() { // 1. 初始化：将所有入度为0的任务加入就绪队列 for (auto& [id, task] : tasks) { if (task.inDegree == 0) { readyQueue.push({task.priority, id}); } } int currentTime = 0; bool gpuBusy = false; int runningTaskId = -1; int finishTime = -1; while (!readyQueue.empty() || !eventQueue.empty() || gpuBusy) { // 2. 处理已完成的事件（任务结束） if (gpuBusy && currentTime >= finishTime) { gpuBusy = false; executionOrder.push_back(runningTaskId); // 释放任务，更新后继任务的入度 for (int nextId : tasks[runningTaskId].nextTasks) { tasks[nextId].inDegree--; if (tasks[nextId].inDegree == 0) { readyQueue.push({tasks[nextId].priority, nextId}); } } } // 3. 如果GPU空闲且有就绪任务，则开始执行 if (!gpuBusy && !readyQueue.empty()) { auto [prio, id] = readyQueue.top(); readyQueue.pop(); runningTaskId = id; finishTime = currentTime + tasks[id].duration; eventQueue.push({finishTime, id}); gpuBusy = true; // 注意：这里不更新currentTime，等待事件驱动推进 } // 4. 推进时间到下一个事件点（如果GPU忙）或处理剩余逻辑 if (gpuBusy && !eventQueue.empty()) { currentTime = eventQueue.top().first; // 跳到下一个任务完成时间 } else if (!readyQueue.empty()) { // GPU空闲但有就绪任务，理论上应该立即执行，这里currentTime不变 continue; } else { // 没有就绪任务也没有进行中的任务，但可能有未处理的事件（理论上不会） break; } } totalTime = currentTime; }

C++方案心得：

• 优势：执行速度最快，内存布局可控，适合处理超大规模任务模拟。
• 坑点：手动管理复杂状态机容易出错，比如时间推进逻辑和GPU状态切换。优先队列的自定义比较器需要小心编写，确保在优先级相同时有确定的次级排序（如任务ID），否则输出序列可能不稳定。
• 注意：使用unordered_map存储任务比vector更灵活（ID可能不连续），但访问速度略慢。如果ID是连续整数，用vector是更好的选择。

3.2 Java解决方案：清晰的结构与强大的并发库

Java方案利用面向对象和丰富的集合框架，代码结构通常更清晰。

关键数据结构：

import java.util.*; class Task { int id; int priority; int duration; int inDegree; List<Integer> nextTasks; // 构造函数、getter/setter省略 } public class GPUScheduler { private Map<Integer, Task> taskMap = new HashMap<>(); // 就绪队列：最大堆，使用PriorityQueue并自定义比较器 private PriorityQueue<Task> readyQueue; // 事件队列：最小堆，按完成时间排序 private PriorityQueue<Event> eventQueue = new PriorityQueue<>(Comparator.comparingInt(e -> e.finishTime)); private List<Integer> executionOrder = new ArrayList<>(); private int totalTime; class Event { int finishTime; Task task; // 构造函数省略 } public GPUScheduler() { // 比较器：优先级降序，同优先级时ID升序（保证确定性） readyQueue = new PriorityQueue<>((a, b) -> { if (a.priority != b.priority) { return b.priority - a.priority; // 降序 } return a.id - b.id; // 升序 }); }

调度核心逻辑： Java的实现逻辑与C++类似，但更注重对象封装和异常安全。

public void schedule() { // 初始化就绪队列 for (Task task : taskMap.values()) { if (task.inDegree == 0) { readyQueue.offer(task); } } int currentTime = 0; Task runningTask = null; int nextFinishTime = Integer.MAX_VALUE; while (!readyQueue.isEmpty() || !eventQueue.isEmpty() || runningTask != null) { // 检查并处理已完成的事件 while (!eventQueue.isEmpty() && eventQueue.peek().finishTime <= currentTime) { Event finished = eventQueue.poll(); executionOrder.add(finished.task.id); for (int nextId : finished.task.nextTasks) { Task next = taskMap.get(nextId); next.inDegree--; if (next.inDegree == 0) { readyQueue.offer(next); } } if (finished.task == runningTask) { runningTask = null; } } // 如果GPU空闲，分配新任务 if (runningTask == null && !readyQueue.isEmpty()) { runningTask = readyQueue.poll(); nextFinishTime = currentTime + runningTask.duration; eventQueue.offer(new Event(nextFinishTime, runningTask)); } // 决定如何推进时间 if (runningTask != null) { // 跳到下一个最早的事件时间 currentTime = eventQueue.peek().finishTime; } else if (!readyQueue.isEmpty()) { // GPU空闲但有就绪任务，时间无需推进，继续循环处理 continue; } else { // 所有任务都已完成或事件队列中剩余事件在未来 if (!eventQueue.isEmpty()) { currentTime = eventQueue.peek().finishTime; } else { break; } } } totalTime = currentTime; }

Java方案心得：

• 优势：代码结构清晰，利用PriorityQueue和Comparator可以非常优雅地实现复杂排序逻辑。垃圾回收机制避免了内存泄漏的担忧。
• 坑点：PriorityQueue的迭代顺序不是排序顺序，不能用来按序查看。在模拟时间推进时，currentTime直接跳到下一个事件点，这是一种“事件驱动”的跳变模拟，比逐单位时间模拟高效得多，但逻辑上需要仔细处理“同时刻”多个事件完成的顺序。
• 注意：对象引用需要小心处理，特别是在将任务从readyQueue移到runningTask再放到eventQueue时，确保是同一个对象。

3.3 Python解决方案：简洁明了的快速实现

Python以其简洁的语法和强大的内置数据结构，非常适合在机试中快速实现算法原型。

关键数据结构与算法：

import heapq from collections import defaultdict, deque class Task: def __init__(self, task_id, priority, duration): self.id = task_id self.priority = priority self.duration = duration self.in_degree = 0 self.next_tasks = [] class GPUScheduler: def __init__(self): self.tasks = {} # id -> Task object # 就绪队列：最大堆，用负优先级实现 self.ready_heap = [] # 事件队列：最小堆，(完成时间, 任务对象) self.event_heap = [] self.execution_order = [] self.total_time = 0 def add_task(self, task_id, priority, duration, dependencies): # 创建任务并建立依赖图 pass # 具体构建逻辑省略 def schedule(self): # 初始化就绪队列 for task in self.tasks.values(): if task.in_degree == 0: # 最大堆技巧：存入(-priority, task.id, task)，通过id解决优先级相同的问题 heapq.heappush(self.ready_heap, (-task.priority, task.id, task)) current_time = 0 gpu_busy = False running_task = None while self.ready_heap or self.event_heap or gpu_busy: # 处理当前时间及之前已完成的事件 while self.event_heap and self.event_heap[0][0] <= current_time: finish_time, finished_task = heapq.heappop(self.event_heap) # 理论上finish_time应等于current_time，这里处理可能的小于情况（时间跳变导致） self.execution_order.append(finished_task.id) for next_id in finished_task.next_tasks: next_task = self.tasks[next_id] next_task.in_degree -= 1 if next_task.in_degree == 0: heapq.heappush(self.ready_heap, (-next_task.priority, next_task.id, next_task)) if finished_task is running_task: running_task = None gpu_busy = False # GPU分配 if not gpu_busy and self.ready_heap: _, _, task_to_run = heapq.heappop(self.ready_heap) running_task = task_to_run gpu_busy = True finish_time = current_time + task_to_run.duration heapq.heappush(self.event_heap, (finish_time, task_to_run)) # 时间推进策略 if gpu_busy: # 跳到下一个事件的完成时间 if self.event_heap: current_time = self.event_heap[0][0] else: # 理论上不会发生 break elif self.ready_heap: # GPU空闲但有就绪任务，时间不推进，继续循环 continue else: # 没有就绪任务，GPU空闲，但事件队列还有未来事件 if self.event_heap: current_time = self.event_heap[0][0] else: break self.total_time = current_time

Python方案心得：

• 优势：代码极其简洁，利用heapq模块和负号技巧轻松实现最大堆。collections.defaultdict和deque让图的操作很方便。开发调试速度快。
• 坑点：Python的heapq是最小堆，要实现最大堆需要存入负值。同时，当优先级相同时，我们需要一个稳定的次级键（如task.id）来保证堆排序的确定性，否则heapq会比较整个元组，而元组中包含不可比较的task对象会导致错误。因此我们采用了(-priority, task.id, task)的三元组。
• 注意：Python在超大规模循环下的性能可能成为瓶颈，但在机试的数据规模内通常足够。对象引用机制与Java类似。

3.4 JavaScript (Node.js) 解决方案：事件循环思维的另一种体现

在Node.js环境下，我们可以利用其单线程事件循环的特性来模拟，虽然机试中不常用，但作为一种思路拓展很有意义。

关键数据结构与模拟循环：

class Task { constructor(id, priority, duration) { this.id = id; this.priority = priority; this.duration = duration; this.inDegree = 0; this.nextTasks = []; } } class GPUScheduler { constructor() { this.tasks = new Map(); // 就绪队列：使用数组+自定义排序模拟最大堆，或使用第三方库如 `heap` this.readyQueue = []; // 事件队列：按完成时间排序的数组 this.eventQueue = []; // 实际应用中可用最小堆优化 this.executionOrder = []; this.totalTime = 0; } // 自定义最大堆比较函数 _readyQueueComparator(a, b) { if (a.priority !== b.priority) { return b.priority - a.priority; } return a.id - b.id; } // 事件队列比较函数（按完成时间升序） _eventQueueComparator(a, b) { return a.finishTime - b.finishTime; } schedule() { // 初始化就绪队列 for (const task of this.tasks.values()) { if (task.inDegree === 0) { this.readyQueue.push(task); } } this.readyQueue.sort(this._readyQueueComparator); // 初始排序 let currentTime = 0; let runningTask = null; while (this.readyQueue.length > 0 || this.eventQueue.length > 0 || runningTask) { // 处理已到期事件 let eventProcessed = false; while (this.eventQueue.length > 0 && this.eventQueue[0].finishTime <= currentTime) { const event = this.eventQueue.shift(); this.executionOrder.push(event.task.id); eventProcessed = true; for (const nextId of event.task.nextTasks) { const nextTask = this.tasks.get(nextId); nextTask.inDegree--; if (nextTask.inDegree === 0) { this.readyQueue.push(nextTask); this.readyQueue.sort(this._readyQueueComparator); // 插入后重新排序 } } if (event.task === runningTask) { runningTask = null; } } // GPU分配 if (!runningTask && this.readyQueue.length > 0) { runningTask = this.readyQueue.shift(); const finishTime = currentTime + runningTask.duration; const newEvent = { finishTime, task: runningTask }; this.eventQueue.push(newEvent); this.eventQueue.sort(this._eventQueueComparator); } // 时间推进决策 if (runningTask) { // 跳到下一个事件的完成时间 if (this.eventQueue.length > 0) { currentTime = this.eventQueue[0].finishTime; } else { // 理论上不会发生 break; } } else if (this.readyQueue.length > 0) { // GPU空闲，有就绪任务，时间不推进，继续下一轮循环处理 continue; } else { // 没有就绪任务，GPU空闲，检查未来事件 if (this.eventQueue.length > 0) { currentTime = this.eventQueue[0].finishTime; } else { break; } } } this.totalTime = currentTime; } }

JavaScript方案心得：

• 优势：思维模式与前端/后端异步编程一脉相承，将任务完成视为“事件回调”。代码结构易于理解。
• 坑点：数组的shift()和push()后再sort()，在数据量大时性能很差（O(n log n)）。在严肃的解决方案中，应该实现一个真正的二叉堆，或者使用MinHeap/MaxHeap类。这恰恰是机试可能考察的点：你是否意识到并优化了这里的数据结构。
• 注意：在Node.js环境下，如果真想模拟“时间”，可以使用setTimeout，但那完全偏离了算法题的本意。这里我们是在用同步逻辑模拟异步调度。

3.5 C语言解决方案：贴近系统底层的实现

C语言方案最具挑战性，需要手动管理一切，但最能体现基本功。

关键数据结构与手动管理：

#include <stdio.h> #include <stdlib.h> #define MAX_TASKS 100000 typedef struct Task { int id; int priority; int duration; int inDegree; int nextCount; int nextTasks[100]; // 假设最大出度，动态分配更好但更复杂 } Task; typedef struct HeapItem { int priority; int id; // 可能还需要一个指向Task的指针或索引 } HeapItem; // 手动实现一个最大堆（针对就绪队列） typedef struct PriorityQueue { HeapItem* data; int size; int capacity; } PriorityQueue; // 一系列堆操作函数：heap_init, heap_push, heap_pop 等（此处省略实现细节） Task tasks[MAX_TASKS]; PriorityQueue readyQueue; // 事件队列也需要一个最小堆，实现类似

调度核心逻辑（伪代码风格）： C语言的实现框架与C++类似，但所有容器都需要自己实现。

void schedule(int numTasks) { // 初始化就绪堆 for (int i = 0; i < numTasks; i++) { if (tasks[i].inDegree == 0) { HeapItem item = {tasks[i].priority, tasks[i].id}; heap_push(&readyQueue, item); } } int currentTime = 0; int runningTaskId = -1; int finishTime = -1; // 需要手动实现一个事件最小堆 eventQueue while (readyQueue.size > 0 || eventQueue.size > 0 || runningTaskId != -1) { // 处理已完成事件 while (eventQueue.size > 0 && peek_min_finish_time(eventQueue) <= currentTime) { Event e = heap_pop_min(&eventQueue); printf("%d ", e.taskId); // 输出执行顺序 Task* finished = &tasks[e.taskId]; for (int j = 0; j < finished->nextCount; j++) { int nextId = finished->nextTasks[j]; tasks[nextId].inDegree--; if (tasks[nextId].inDegree == 0) { HeapItem item = {tasks[nextId].priority, nextId}; heap_push(&readyQueue, item); } } if (e.taskId == runningTaskId) { runningTaskId = -1; } } // GPU分配 if (runningTaskId == -1 && readyQueue.size > 0) { HeapItem item = heap_pop(&readyQueue); runningTaskId = item.id; finishTime = currentTime + tasks[runningTaskId].duration; Event newEvent = {finishTime, runningTaskId}; heap_push_min(&eventQueue, newEvent); } // 时间推进 if (runningTaskId != -1) { if (eventQueue.size > 0) { currentTime = peek_min_finish_time(eventQueue); } else { break; // 异常 } } else if (readyQueue.size > 0) { continue; } else { if (eventQueue.size > 0) { currentTime = peek_min_finish_time(eventQueue); } else { break; } } } printf("\nTotal time: %d\n", currentTime); }

C语言方案心得：

• 优势：对内存和计算过程有绝对控制，无任何运行时开销，代码效率极高。是理解调度器底层原理的最佳方式。
• 坑点：极易出错。手动实现堆、管理动态数组、处理指针和索引都需要极其小心。内存泄漏、数组越界、指针错误是常见问题。在机试的紧张环境下，实现一个健壮的C版本挑战很大。
• 注意：如果任务数量很大，用静态数组（如nextTasks[100]）限制出度不现实。更好的做法是使用动态数组（malloc/realloc）或邻接表，但这进一步增加了复杂度。通常机试中的C语言版本会对数据规模有较宽松的限制。

4. 常见问题与调试技巧实录

在实际编码和调试这类调度问题时，我踩过不少坑，也总结了一些通用的排查思路。

4.1 输出顺序与预期不符

这是最常见的问题。可能的原因和排查步骤：

1. 优先级比较逻辑错误：确认是最大优先还是最小优先。priority_queue在C++中默认是最大堆（top()是最大元素），但自定义比较器容易写反。在Python中使用heapq时，忘记用负号实现最大堆。
2. 次级排序缺失：当两个任务优先级相同时，如果没有定义次级排序规则（如按ID升序），不同语言或不同运行环境下，堆的弹出顺序可能是不确定的，导致输出序列每次运行可能不同。务必在比较器中加入次级键。
3. 依赖处理时机错误：任务完成后，对其后继任务入度的减少操作，以及将入度减为0的任务加入就绪队列的操作，必须在同一时间点原子化完成。不能先减入度，等下一轮循环再检查加入，否则在复杂依赖下可能导致调度顺序错误。
4. 时间推进逻辑bug：在“事件驱动”的跳变模拟中，currentTime应该直接跳到下一个最早的事件完成时间。如果错误地逐单位时间递增，不仅效率低下，还可能因为任务完成和就绪任务加入的时序问题导致错误。检查你的while循环条件和时间更新语句。

调试技巧：构造一个小型测试用例，包含优先级相同、有简单依赖关系的任务，手动模拟一遍你的调度器，在纸上画出每个时刻的就绪队列、事件队列和GPU状态，与程序输出对比。

4.2 程序陷入死循环或提前结束

1. 循环依赖未检测：这是死循环的常见原因。在初始化构建依赖图后，应该先跑一遍拓扑排序检测环。如果存在环，则直接返回错误或空结果。
2. 就绪队列和事件队列状态更新不同步：确保一个任务从“运行中”转移到“已完成”时，其状态在所有数据结构中被正确清除。例如，在C++/Java中，runningTask引用或ID需要被置空或设为-1。
3. 边界条件处理不当：当就绪队列和事件队列都为空，但gpuBusy标志还为true时，或者反过来，会导致循环判断条件出错。仔细检查while循环的条件组合，确保覆盖所有可能的状态（就绪非空、事件非空、GPU忙/闲）。

4.3 性能不达标

对于大规模数据（如10万个任务），O(n²)的算法必然超时。

1. 数据结构选择：必须使用堆（优先队列）来管理就绪任务和事件，保证插入和删除是O(log n)。使用数组线性查找最大优先级任务是灾难性的。
2. 避免频繁排序：在JavaScript的示例中，每次插入就绪队列后都调用sort()是O(n log n)的。应该改为手动维护堆结构，或者仅在必要时进行“堆化”操作。
3. 图的存储：使用邻接表（如vector<vector<int>>或List<Integer>[]）而不是邻接矩阵来存储任务依赖关系，以节省空间和时间。

4.4 多语言实现的通用陷阱速查表

5. 从解题到优化：高级思路探讨

如果机试题目在此基础上增加难度，可能会考察以下方向，了解这些能让你在面试中脱颖而出。

5.1 支持多GPU核心调度

这是最自然的扩展。题目可能变为有M个相同的GPU核心。思路需要升级：

• 就绪队列：仍然只有一个全局的基于优先级的就绪队列。
• GPU状态：维护一个大小为M的“核心空闲列表”或“正在运行的任务列表”。
• 调度循环：在每个调度点（时间推进或任务完成时），先释放已完成任务占用的核心，然后尽可能多地从就绪队列中取出任务，分配给空闲的核心，直到核心用完或就绪队列为空。
• 事件队列：每个运行的任务都会产生一个完成事件。事件队列需要记录是哪个核心释放。
• 挑战：当优先级相同的任务多于空闲核心时，如何选择？通常按任务ID等次级键顺序分配即可。

这本质上将问题从单资源调度变成了多资源调度，算法框架不变，但状态管理更复杂。

5.2 抢占式优先级调度

在非抢占式调度中，一个任务一旦开始就必须执行完。而抢占式允许高优先级任务抢占低优先级任务的执行。

• 事件类型：除了“任务完成”事件，还需要“新任务到达”事件（如果题目有定义到达时间）。
• 调度决策点：不仅在任务完成时，在任何新任务到达或就绪队列优先级变化时，都需要检查：当前运行的任务优先级是否低于就绪队列中的最高优先级任务？如果是，则抢占。
• 实现：被抢占的任务剩余执行时间需要保存，并将其重新放回就绪队列（或一个特殊的“被中断”队列）。事件队列需要处理这种“剩余时间”的计算。
• 注意：抢占本身有开销，题目中可能会定义“上下文切换时间”。

5.3 考虑I/O或通信等待

真实GPU任务可能涉及数据搬运（CPU到GPU，GPU到GPU）。题目可能引入“计算阶段”和“I/O阶段”。

• 任务模型变化：一个任务可能变成由多个子阶段（计算、I/O、计算...）组成。
• 资源类型：GPU计算核心和I/O总线（或内存带宽）成为两种不同的资源，需要分别调度。
• 调度器设计：可能需要两个调度队列和两个资源状态管理器。任务在不同阶段间迁移，状态机更复杂。这通常就属于更专业的“异构计算调度”范畴了，在机试中可能只会给出简化模型。

面对这些扩展，最重要的是保持冷静，将复杂问题分解为你已经熟悉的模块（任务管理、队列、事件驱动），然后逐步增量修改你的单核、非抢占、无I/O的基线代码。在编码前，先在注释或草稿纸上画清楚状态转换图，这是避免逻辑混乱的关键。