本文是专栏《机器人人机交互与控制实践》第 8 篇。前面几篇反复出现“输入线程”“网络线程”“固定频率循环”“界面卡住”，这一篇专门讨论上位机程序本身的架构。
上位机的实时性问题有一个共同特征：平均值看起来一切正常，问题藏在尾部。循环平均周期是 10.0 ms，但每隔几秒有一拍晚了 300 ms；CPU 占用只有 15%，但某个线程每一拍都晚 5 ms。机器人表现为偶尔“顿一下”，现场很难复现，日志里也看不出什么。
本文的方法是：先定义一个可以测量的指标，然后用实验逐一量化上位机常见的实时性杀手：循环写法、时钟选择、GIL、垃圾回收、锁与 I/O、操作系统调度，最后给出进程和线程的划分方案。
先说清楚两点前提：
- 上位机不承担硬实时任务。需要严格保证时序的控制回路应该放在 MCU 上（第 7 篇）；上位机的抖动应该只影响操作的平顺性，而不影响安全。但“软实时”不等于“随便”，一次 300 ms 的停顿，足以让操作员失去对机器人的控制感；
- 本文所有实验都是实测：Linux，Python 3.12，只有 1 个 CPU 核。单核环境会放大线程和进程之间的竞争，多核机器上部分数字会更好看，但结论的方向不变。Windows 上的差异会单独说明。
1. 先定义要测什么：迟到量
固定频率循环的每一拍都有一个“应该开始的时刻”，迟到量就是实际开始时刻减去应该开始的时刻
