3. QNX内核与进程管理：进程与线程、调度策略、优先级反转与解决
大家好，我是你们的老朋友。今天我们来聊聊QNX内核里最核心的一块——进程与线程管理。说实话，这块内容我做了十几年驱动，每次遇到系统卡死或者响应延迟，十有八九都是调度策略没用好。咱们今天就把这块硬骨头啃下来。
3.1 进程与线程：QNX里的“人”和“手”
先打个比方。进程就像是一个公司，有自己的独立办公室（地址空间）、财务（资源）、规章制度（权限）。线程呢，就是公司里干活的员工。一个公司可以有多个员工，共享办公室和资源。
在QNX里，进程是资源分配的最小单位。每个进程有自己的4GB虚拟地址空间（32位下），互不干扰。线程是CPU调度的最小单位。同一个进程里的线程，共享代码段、数据段和堆。
关键区别：
- 进程间通信需要IPC（消息、共享内存等），开销大
- 线程间通信直接读写共享变量，但要加锁
- 进程崩溃不影响其他进程，线程崩溃可能拖垮整个进程
我在项目中遇到过一个问题：一个多线程的数据采集程序，偶尔会莫名其妙地挂掉。查了三天，发现是线程A释放了某个缓冲区，线程B还在用。嗯，这就是典型的线程同步问题。后来改用QNX的同步机制——pthread_mutex_t，问题就解决了。
3.2 调度策略：谁先跑，谁后跑
QNX是实时操作系统，调度策略直接决定了你的系统能不能在规定时间内响应。说白了，就是CPU这个“老板”怎么分配工作时间给各个“员工”（线程）。
QNX支持三种调度策略：FIFO、RR和SPORADIC。咱们一个一个看。
3.2.1 FIFO调度（先进先出）
FIFO，全称First In First Out。线程按优先级排队，同优先级的线程，谁先就绪谁先跑。除非线程自己主动让出CPU（比如调用sleep、阻塞在IPC上），或者被更高优先级的线程抢占，否则它会一直跑下去。
// 设置FIFO调度策略的示例
struct sched_param param;
param.sched_priority = 30; // 优先级设为30
pthread_setschedparam(thread_id, SCHED_FIFO, ¶m);
我的经验：FIFO适合那些需要连续执行、不能被打断的任务。比如数据采集线程，一次采集必须完整做完，中间切出去就丢数据了。我曾经在一个雷达信号处理项目里，把核心算法线程设成FIFO，优先级最高，效果很好。
3.2.2 RR调度（轮转）
RR，Round Robin。和FIFO类似，也是按优先级排队。但区别在于：同优先级的线程，每个线程只能跑一个时间片（默认4ms，可以配置）。时间片用完了，就轮到下一个同优先级的线程。
// 设置RR调度策略
param.sched_priority = 20;
pthread_setschedparam(thread_id, SCHED_RR, ¶m);
RR的好处是公平。不会出现一个线程霸占CPU，其他同优先级线程饿死的情况。适合那些计算量差不多的任务，比如多个传感器数据预处理线程。
注意：时间片不是越小越好。我见过有人把时间片设成1ms，结果上下文切换开销占了CPU的30%以上。系统响应是快了，但有效计算时间少了。一般4ms到10ms是比较合理的范围。
3.2.3 SPORADIC调度（零星调度）
这个策略是QNX的特色，也是很多工程师容易忽略的。SPORADIC专门用来处理那些“平时不干活，一干活就要马上响应”的任务。
它的原理是这样的：给线程分配一个“预算”（budget）和“周期”（period）。在周期内，线程最多可以跑预算那么多时间。预算用完了，线程的优先级就降到后台优先级。等到下一个周期开始，预算恢复，优先级也恢复。
// SPORADIC调度参数设置
struct sched_param param;
param.sched_priority = 40; // 正常优先级
param.sched_ss_low_priority = 10; // 后台优先级
param.sched_ss_repl_period.tv_sec = 0;
param.sched_ss_repl_period.tv_nsec = 100000000; // 周期100ms
param.sched_ss_init_budget.tv_sec = 0;
param.sched_ss_init_budget.tv_nsec = 10000000; // 预算10ms
pthread_setschedparam(thread_id, SCHED_SPORADIC, ¶m);
为什么要用SPORADIC？举个例子：一个网络数据包处理线程。平时可能几百毫秒才来一个包，但一旦来了，必须在几毫秒内处理完。如果用FIFO高优先级，它会一直占着CPU，浪费资源。用SPORADIC，平时低优先级，有包来了就高优先级处理，处理完又降回去。
3.3 优先级反转：一个经典的坑
优先级反转，说白了就是：一个低优先级的线程拿着锁不放，导致高优先级线程被阻塞。更糟糕的是，中间还有一个中等优先级的线程在跑，低优先级线程根本拿不到CPU去释放锁。
我当年第一次遇到这个问题，是在一个电机控制项目里。电机控制线程优先级最高，但它要读取一个传感器数据，这个数据被一个低优先级的日志线程锁着。日志线程正写到一半，一个中等优先级的UI刷新线程抢走了CPU。结果电机控制线程等锁等了200ms，电机直接抖了一下。嗯，那次差点把设备搞坏。
3.3.1 解决方案一：优先级继承
QNX默认就支持优先级继承。当高优先级线程被低优先级线程的锁阻塞时，低优先级线程会临时“继承”高优先级的优先级。这样它就能尽快跑完，释放锁。
// 使用优先级继承的互斥锁
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr);
核心要点：优先级继承只对当前持有锁的线程生效。如果多个线程在等同一个锁，只有当前持有锁的那个会提升优先级。其他等待的线程不会。
3.3.2 解决方案二：优先级天花板
另一种方法是优先级天花板协议。给每个锁设定一个“天花板优先级”，任何线程拿到这个锁，优先级自动提升到天花板。这样不管谁拿锁，都能快速跑完。
// 使用优先级天花板
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_PROTECT);
pthread_mutexattr_setprioceiling(&attr, 50); // 天花板优先级50
我个人习惯用优先级继承。因为天花板协议需要你事先知道所有可能拿锁的线程的最高优先级，万一漏了，还是会有问题。优先级继承是动态的，更安全。
3.3.3 解决方案三：避免共享资源
这是最彻底的办法。能不用锁就不用锁。比如用无锁队列、每个线程独立的数据缓冲区。我在一个高速数据采集项目里，就是用双缓冲+原子操作，完全避免了锁竞争，性能提升了30%。
避坑指南：我曾经在一个项目里，把所有线程都设成FIFO最高优先级，想着“这样响应最快”。结果系统直接卡死——因为最高优先级的线程之间互相抢锁，死锁了。记住：优先级不是越高越好，合理分配才是王道。
3.4 实战建议：如何选择调度策略
| 任务类型 | 推荐策略 | 优先级 | 说明 |
|---|---|---|---|
| 中断处理/硬实时 | FIFO | 最高（50-63） | 必须立即响应，不能被打断 |
| 周期性控制任务 | FIFO或RR | 高（30-49） | 比如电机控制、PID计算 |
| 数据采集/处理 | RR | 中（10-29） | 多个同类任务，公平分配CPU |
| 偶发响应任务 | SPORADIC | 动态 | 网络包处理、事件响应 |
| 后台/日志任务 | 默认（分时） | 低（1-9） | 不要求实时性 |
最后说一句：调度策略没有银弹。每个项目都要根据实际需求去调。我建议你在开发阶段，用QNX的pidin命令和tracelogger工具，实时监控线程的调度情况。看到哪个线程长时间霸占CPU，或者哪个高优先级线程频繁被阻塞，那就是需要优化的地方。
好了，这一章的内容就到这里。下一章我们讲块设备驱动框架，到时候会用到今天讲的线程和同步知识。记得动手写代码试试，光看是学不会的。