4、优先级管理：优先级范围与映射、优先级继承协议、优先级天花板协议
好，咱们来聊聊优先级管理。说实话，这部分内容在实时系统里特别关键。你想想看，任务优先级要是没管好，系统跑着跑着就可能出大问题。我在项目中见过不少因为优先级配置不当导致的死锁和优先级反转，那排查起来真是让人头大。
4.1 优先级范围与映射
QNX 的优先级范围是多少？嗯，从 0 到 255，一共 256 个级别。数字越大，优先级越高。0 是空闲任务，255 是最高优先级的中断服务线程。不过，我个人习惯把 1 到 63 留给用户线程，64 到 255 给系统内核和中断用。这样分，心里踏实。
但这里有个坑——不同处理器对优先级数量的支持不一样。比如有些嵌入式芯片只支持 32 级硬件优先级。那怎么办？QNX 会做映射。把 256 级软件优先级映射到硬件支持的级别上。说白了，就是软件层帮你兜底。
重要提示： 优先级映射不是线性的。QNX 内部有一套算法，确保高优先级任务在硬件上也能获得相对高的优先级。但映射后，原本相邻的两个优先级可能被合并到同一个硬件优先级上。所以，别把优先级设得太密，比如 100 和 101，其实效果差不多。
我建议你这样做：
- 关键实时任务：优先级设在 200-254 之间
- 普通实时任务：优先级设在 100-199 之间
- 非实时后台任务：优先级设在 1-99 之间
- 空闲任务：优先级 0
这样分层，既保证了实时性，又不会让低优先级任务饿死。我曾经在一个项目中，把所有任务都设成了 200 以上，结果低优先级的日志任务根本跑不起来。嗯，那教训挺深刻的。
4.2 优先级继承协议
优先级继承协议，说白了就是解决优先级反转问题的。什么是优先级反转？举个例子：
有三个任务：高优先级任务 H，中优先级任务 M，低优先级任务 L。L 先拿到了一个共享资源（比如一把锁）。H 来了，想拿同一把锁，但被 L 占着，所以 H 被阻塞。这时候 M 来了，它不需要那把锁，但它优先级比 L 高，所以 M 抢占了 L。结果呢？H 得等 M 跑完，再等 L 释放锁。H 明明优先级最高，却被 M 和 L 拖住了。这就是优先级反转。
优先级继承协议怎么解决？当 H 被 L 阻塞时，L 临时继承 H 的优先级。也就是说，L 的优先级被提升到和 H 一样高。这样 M 就抢不了 L 了。L 赶紧跑完，释放锁，然后 L 的优先级降回原来的值。H 拿到锁，继续执行。
我的经验： 优先级继承协议在 QNX 里是默认开启的。你只要用 pthread_mutexattr_setprotocol 设置成 PTHREAD_PRIO_INHERIT 就行。但要注意，这个协议会增加上下文切换的开销。因为每次优先级提升和恢复，内核都要重新调度。所以，别滥用，只在确实有共享资源竞争的地方用。
代码示例：
#include <pthread.h>
pthread_mutex_t mutex;
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);
pthread_mutex_init(&mutex, &attr);
// 然后正常使用 mutex 即可
pthread_mutex_lock(&mutex);
// 临界区代码
pthread_mutex_unlock(&mutex);你看，代码很简单。但背后的调度逻辑，内核帮你处理好了。
4.3 优先级天花板协议
优先级天花板协议，是另一种防止优先级反转的方法。它比优先级继承更激进。怎么做的呢？每个共享资源都有一个“天花板优先级”。这个天花板优先级，等于所有可能使用这个资源的任务中的最高优先级。
当一个任务拿到锁时，它的优先级立刻被提升到天花板优先级。不管有没有高优先级任务在等。这样，任何比天花板优先级低的任务都无法抢占它。说白了，就是“一刀切”，简单粗暴。
注意： 优先级天花板协议可能导致不必要的优先级提升。比如，低优先级任务 L 拿了一把锁，天花板优先级是 200。但此时根本没有高优先级任务在等这把锁。L 却被提升到了 200，白白浪费了 CPU 时间。所以，这个协议适合在资源竞争非常激烈、且任务数量固定的场景下使用。
在 QNX 里设置优先级天花板：
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_PROTECT);
pthread_mutexattr_setprioceiling(&attr, 200); // 设置天花板优先级为 200
pthread_mutex_init(&mutex, &attr);我个人更倾向于优先级继承协议。因为它更灵活，只在必要时才提升优先级。但如果你对系统的实时性要求极高，且所有任务和资源都是静态确定的，那优先级天花板协议也是个不错的选择。
4.4 两种协议的对比
| 特性 | 优先级继承协议 | 优先级天花板协议 |
|---|---|---|
| 触发条件 | 高优先级任务被阻塞时才提升 | 拿到锁就提升，不管有没有竞争 |
| 开销 | 较小，但每次提升/恢复需要调度 | 较大，因为频繁提升优先级 |
| 适用场景 | 资源竞争不频繁，任务动态变化 | 资源竞争激烈，任务静态固定 |
| 死锁风险 | 较低 | 较低，但可能造成优先级浪费 |
嗯，表格一看就清楚了。实际项目中怎么选？我建议你这样做：
- 如果系统里任务数量不多，且你清楚每个任务会用哪些资源，用优先级天花板协议
- 如果任务动态创建、销毁，或者资源竞争模式不确定，用优先级继承协议
- 如果对实时性要求极高，且能接受一定的优先级浪费，用优先级天花板协议
我曾经在一个多传感器融合的项目里，一开始用了优先级天花板协议。结果发现低优先级任务被频繁提升，导致系统整体吞吐量下降。后来换成优先级继承协议，问题就解决了。所以，没有绝对的好坏，得看你的具体场景。
核心要点： 优先级管理的本质，是在实时性、公平性和系统开销之间找平衡。优先级继承协议是“按需分配”，优先级天花板协议是“预分配”。理解了这个，你就能根据项目需求做出合理选择。
好了，优先级管理这部分就讲到这里。记住，优先级不是越高越好，关键是合理。下节课咱们聊聊任务同步与通信，那又是另一番天地了。