1
调度的三大目标：
2

3
    吞吐量 (Throughput)
4
   单位时间完成的作业数
5
         /\
6
        /  \
7
       /    \
8
      /      \
9
     /________\
10
响应时间              公平性 (Fairness)
11
(Response Time)      每个进程都有机会运行
12

13
三者不可兼得：
14
- 追求高吞吐 → 偏向短作业 → 长作业「饿死」→ 不公平
15
- 追求低延迟 → 频繁切换 → 上下文切换开销大 → 吞吐下降
16
- 追求绝对公平 → 一视同仁 → 交互进程得不到优先 → 响应差

1
MLFQ 规则（简化版）：
2
┌─────────────────────────────────────────────┐
3
│  规则1: 优先级高的队列先运行                   │
4
│  规则2: 同优先级队列内，时间片轮转              │
5
│  规则3: 新进程进入最高优先级队列                │
6
│  规则4: 用完时间片未完成 → 降级到下一级          │
7
│         时间片用完前主动放弃 → 保持当前级别       │
8
│  规则5: 定期把所有进程提升回最高优先级           │
9
│         （防止长进程永久饿死——Priority Boost）   │
10
└─────────────────────────────────────────────┘
11

12
为什么 MLFQ 优秀？
13
- 短进程快速完成（在高优先级队列就搞定了）
14
- 长进程在后台慢慢跑（被降级到低优先级）
15
- I/O 密集型自动留在高优先级（没到时间片就阻塞了）
16
- CPU 密集型自动降到低优先级（每次都耗尽时间片）
17
→ 不需要预知进程类型，自适应！

1
// 策略 1：固定步长 (Fixed Timestep)
2
// 适用：确定性要求高的游戏（格斗、RTS 录像回放、帧同步网络游戏）
3
class GameLoop_Fixed {
4
    constexpr static double TICK_RATE = 1.0 / 60.0;  // 16.67ms
5

6
    void run() {
7
        auto previous = clock::now();
8
        double lag = 0.0;
9

10
        while (running) {
11
            auto current = clock::now();
12
            double elapsed = std::chrono::duration<double>(current - previous).count();
13
            previous = current;
14
            lag += elapsed;
15

16
            while (lag >= TICK_RATE) {
17
                fixedUpdate(TICK_RATE);  // 固定步长更新
18
                lag -= TICK_RATE;
19
            }
20

21
            render(lag / TICK_RATE);  // 插值渲染
22
        }
23
    }
24

25
    // 优点：确定性（replay 可以精确复现）
26
    //       网络同步友好
27
    //       物理模拟稳定
28
    // 缺点：如果机器性能不够 → 追赶螺旋 (Death Spiral)
29
    //       一帧做不完 → lag 累积 → 下一帧更做不完
30
};
31

32
// 策略 2：可变步长 (Variable Timestep)
33
// 适用：对确定性要求不高的游戏（多数单机游戏）
34
class GameLoop_Variable {
35
    void run() {
36
        auto previous = clock::now();
37

38
        while (running) {
39
            auto current = clock::now();
40
            double dt = std::chrono::duration<double>(current - previous).count();
41
            previous = current;
42

43
            // 防止大 delta（如调试断点后）
44
            dt = std::min(dt, 0.1);  // 上限 100ms
45

46
            update(dt);   // 用实际 delta 时间更新
47
            render();
48
        }
49
    }
50

51
    // 优点：简单
52
    //       不会追赶
53
    // 缺点：物理不稳定（不同帧率的物理结果不同）
54
    //       网络同步困难
55
};
56

57
// 策略 3：半固定步长 (Semi-Fixed Timestep)
58
// 适用：大多数现代游戏引擎（UE5, Unity）
59
class GameLoop_SemiFixed {
60
    constexpr static double FIXED_DT = 1.0 / 60.0;
61
    constexpr static int MAX_UPDATES = 5;  // 最多追赶 5 帧
62

63
    void run() {
64
        auto previous = clock::now();
65
        double accumulator = 0.0;
66

67
        while (running) {
68
            auto current = clock::now();
69
            double frame_time = std::chrono::duration<double>(current - previous).count();
70
            previous = current;
71

72
            // 防止螺旋
73
            frame_time = std::min(frame_time, 0.25);  // 帧率不低于 4fps
74

75
            accumulator += frame_time;
76

77
            int updates = 0;
78
            while (accumulator >= FIXED_DT && updates < MAX_UPDATES) {
79
                fixedUpdate(FIXED_DT);   // 物理用固定步长
80
                accumulator -= FIXED_DT;
81
                updates++;
82
            }
83

84
            // 如果追不上，丢弃多余的累积（避免螺旋）
85
            if (updates >= MAX_UPDATES) {
86
                accumulator = 0.0;
87
            }
88

89
            double alpha = accumulator / FIXED_DT;  // 插值因子
90
            render(alpha);
91
        }
92
    }
93

94
    // 优点：物理确定 + 防追赶螺旋
95
    // 缺点：略微复杂
96
};

1
vsync (垂直同步) 和调度的经典冲突：
2

3
场景：60Hz 显示器，游戏引擎目标 60fps
4

5
帧循环 1（理想情况）：
6
  [----Update 8ms----][--Render 6ms--][等 vsync 2.67ms][--Present--]
7
                                                ↑
8
                                          Sleep(1) 或忙等
9

10
帧循环 2（Sleep 精度问题）：
11
  [----Update 12ms----][--Render 3ms--][Sleep(1) 实际睡了 5ms]
12
  → Present 延迟 → 错过 vsync → 等下一个 vsync → 掉到 30fps！
13

14
  Windows 默认时钟分辨率：15.6ms (64Hz)
15
  Sleep(1) 的实际精度：1-16ms 不等
16

17
  解决方案：
18
  1. timeBeginPeriod(1) → 将系统时钟分辨率提升到 1ms
19
     → Sleep(1) 精度提升到 1-2ms
20
     → 代价：增加系统功耗（CPU 更频繁被唤醒）
21

22
  2. 不用 Sleep，用忙等 (Busy Wait)：
23
     while (remaining > 0) {
24
         if (remaining < 100us) {
25
             // 最后 100us 用忙等（精确但不费电太久）
26
             while (clock::now() < target) { _mm_pause(); }
27
         } else {
28
             Sleep(0);  // 或 Sleep(1)
29
             remaining = target - clock::now();
30
         }
31
     }
32

33
  3. 使用高精度可等待定时器：
34
     Windows: CreateWaitableTimerEx (高精度)
35
     Linux:   timerfd_create + epoll

1
// Windows 高精度计时器
2
class Timer_Windows {
3
    LARGE_INTEGER _frequency;
4
    LARGE_INTEGER _start;
5

6
public:
7
    Timer_Windows() {
8
        QueryPerformanceFrequency(&_frequency);  // 通常是 10MHz
9
        QueryPerformanceCounter(&_start);
10
    }
11

12
    double elapsed_ms() {
13
        LARGE_INTEGER now;
14
        QueryPerformanceCounter(&now);
15
        return (now.QuadPart - _start.QuadPart) * 1000.0 / _frequency.QuadPart;
16
    }
17

18
    double elapsed_us() {
19
        LARGE_INTEGER now;
20
        QueryPerformanceCounter(&now);
21
        return (now.QuadPart - _start.QuadPart) * 1'000'000.0 / _frequency.QuadPart;
22
    }
23

24
    // 精度：通常 < 1μs
25
    // 开销：~20-50ns（读取 TSC 寄存器）
26
};

1
// Linux 高精度计时器
2
class Timer_Linux {
3
    timespec _start;
4

5
public:
6
    Timer_Linux() {
7
        clock_gettime(CLOCK_MONOTONIC, &_start);  // 单调时钟，不受系统时间调整影响
8
    }
9

10
    double elapsed_ms() {
11
        timespec now;
12
        clock_gettime(CLOCK_MONOTONIC, &now);
13
        return (now.tv_sec - _start.tv_sec) * 1000.0
14
             + (now.tv_nsec - _start.tv_nsec) / 1'000'000.0;
15
    }
16

17
    double elapsed_ns() {
18
        timespec now;
19
        clock_gettime(CLOCK_MONOTONIC, &now);
20
        return (now.tv_sec - _start.tv_sec) * 1'000'000'000.0
21
             + (now.tv_nsec - _start.tv_nsec);
22
    }
23

24
    // CLOCK_MONOTONIC：不受 NTP 校准影响，用于测量时间间隔
25
    // CLOCK_REALTIME：  墙上时钟，可被 NTP 调整
26
    // CLOCK_THREAD_CPUTIME_ID：本线程消耗的 CPU 时间
27
    // 精度：通常 ~20-50ns（通过 vDSO 在用户态完成，不走系统调用！）
28
    //       vDSO = 内核把 clock_gettime 映射到用户态内存页
29
};

1
音频回调的硬性约束：
2

3
假设：
4
- 采样率: 48000 Hz
5
- 缓冲区大小: 256 samples
6
- 缓冲区时长: 256 / 48000 = 5.33ms
7

8
这意味着：
9
音频回调线程每 5.33ms 被唤醒一次，
10
必须在 5.33ms 内完成处理（混音、DSP 效果、编码），
11
否则音频缓冲区下溢 → 爆音/杂音！
12

13
如果操作系统调度器把音频线程换下超过 5.33ms：
14
→ 即使 CPU 总体利用率只有 50%
15
→ 音频也会爆音！

1
// 音频线程的正确配置（Linux）
2
#include <pthread.h>
3
#include <sched.h>
4

5
void setup_audio_thread() {
6
    pthread_t thread = pthread_self();
7

8
    // 设置为 SCHED_FIFO 实时调度
9
    sched_param param;
10
    param.sched_priority = 80;  // 0-99，越高优先级越高
11
                                // 80 是音频的典型选择
12
                                // 不能设 99（可能抢占内核关键线程）
13

14
    pthread_setschedparam(thread, SCHED_FIFO, &param);
15

16
    // 锁定内存——防止音频缓冲区被 swap 出去
17
    mlockall(MCL_CURRENT | MCL_FUTURE);
18

19
    // 效果：
20
    // 1. 音频线程不会被普通 SCHED_NORMAL 线程抢占
21
    // 2. 只可能被更高优先级的 SCHED_FIFO 线程抢占
22
    // 3. 内存不会被换出（避免 page fault 导致的延迟尖峰）
23
}

1
Windows MMCSS (Multimedia Class Scheduler Service)：
2

3
Windows 的音频调度方案更成熟——通过 MMCSS：
4

5
1. 进程注册为「音频」任务：
6
   AvSetMmThreadCharacteristics(L"Audio", &taskIndex);
7

8
2. MMCSS 自动将线程提升到 MMCSS 调度类
9
   - 优先级：比普通线程高，但低于系统关键线程
10
   - 时间片：更短（保证快速轮转）
11
   - 不会被普通线程饿死
12

13
3. 可用类别：
14
   - "Audio"      → 音频渲染/捕获
15
   - "Capture"    → 视频捕获
16
   - "Playback"   → 视频播放
17
   - "Games"      → 游戏（Windows 10+）
18
   - "Pro Audio"  → 专业音频（DAW，极低延迟）
19

20
4. 典型用法：
21
   DWORD taskIndex = 0;
22
   HANDLE handle = AvSetMmThreadCharacteristics(L"Audio", &taskIndex);
23
   // ... 音频回调线程运行 ...
24
   AvRevertMmThreadCharacteristics(handle);

1
一个游戏引擎的线程调度层次：
2

3
优先级从高到低：
4

5
┌────────────────────────────────────────────────────┐
6
│ 实时级 (SCHED_FIFO / MMCSS Pro Audio)              │
7
│ ├── 音频回调线程         优先级 80 | 周期 ~5ms      │
8
│ └── VR 追踪线程          优先级 75 | 周期 ~1ms      │
9
│    (VR 的 ATW/ASW 需要亚毫秒级响应)                 │
10
├────────────────────────────────────────────────────┤
11
│ 高优先级 (SCHED_FIFO / MMCSS Games)                │
12
│ ├── 渲染提交线程         优先级 50 | 周期 ~16ms     │
13
│ └── 物理模拟线程         优先级 40 | 周期 ~16ms     │
14
│    (如果独立于主循环运行)                            │
15
├────────────────────────────────────────────────────┤
16
│ 普通级 (SCHED_NORMAL / nice 0)                     │
17
│ ├── 主循环线程 (Update+Render)                      │
18
│ │   大部分游戏引擎的核心线程                         │
19
│ ├── 网络 I/O 线程                                  │
20
│ └── 资源流式加载线程                                │
21
│    (I/O 密集型 → 经常睡眠 → CFS 自动给高优先级)      │
22
├────────────────────────────────────────────────────┤
23
│ 低优先级 (SCHED_NORMAL / nice 5-10)                │
24
│ ├── 文件写入线程（存档、日志）                        │
25
│ ├── 统计数据收集线程                                │
26
│ └── 后台编译着色器线程                              │
27
└────────────────────────────────────────────────────┘
28

29
关键原则：
30
1. 不要把所有线程都设为实时——会互相抢占，整体性能更差
31
2. 只有真正有截止时间要求的线程才用实时调度
32
3. 主循环用普通调度即可——CFS 对 I/O 密集型的自动优化足够好
33
4. 音频是唯一「必须」实时的——缓冲区下溢比掉帧更难接受