3、QNX进程与线程管理：进程创建与销毁、线程调度策略、优先级管理、同步与互斥（Mutex/Condvar）

好，咱们进入第三章。这一章讲的是QNX里最核心的东西——进程和线程怎么管。说实话，很多做Linux转过来的工程师，刚接触QNX时最容易在这块栽跟头。我当年带团队做车载项目时，就因为线程优先级没搞明白，导致一个音频任务被低优先级的日志线程活活饿死。嗯，咱们今天就把这块彻底讲透。

3.1 进程创建与销毁：从spawn到waitpid

在QNX里创建进程，最常用的不是fork，而是spawn()。为什么？因为QNX是微内核，进程间隔离做得非常彻底。你用fork的话，子进程会复制父进程的整个地址空间，这在嵌入式系统里往往是浪费。

我个人习惯用spawn()配合posix_spawnattr_t来设置进程属性。来看个例子：

#include <spawn.h>
#include <sys/wait.h>

pid_t pid;
posix_spawnattr_t attr;
posix_spawnattr_init(&attr);

// 设置调度策略和优先级
struct sched_param param;
param.sched_priority = 20;
posix_spawnattr_setschedparam(&attr, &param);
posix_spawnattr_setschedpolicy(&attr, SCHED_RR);

char *argv[] = {"/usr/bin/my_task", "-c", "config.ini", NULL};
char *envp[] = {"PATH=/usr/bin", NULL};

int ret = posix_spawn(&pid, "/usr/bin/my_task", NULL, &attr, argv, envp);
if (ret != 0) {
    // 处理错误
}

// 等待子进程结束
int status;
waitpid(pid, &status, 0);

销毁进程呢？我建议用SIGTERM信号优雅退出，而不是直接SIGKILL。我在项目中遇到过，直接kill掉一个正在写文件的进程，结果文件系统损坏了。后来我们统一用信号处理机制，让进程自己清理资源。

注意：QNX里进程退出时，它的所有线程也会被销毁。但如果你有共享内存或消息队列，记得在退出前清理。否则会出现资源泄漏，这在长时间运行的嵌入式系统里是致命的。

3.2 线程调度策略：FIFO、RR还是SPORADIC？

QNX支持三种实时调度策略：SCHED_FIFO、SCHED_RR和SCHED_SPORADIC。还有个SCHED_OTHER，但那玩意儿是非实时的，咱们做嵌入式的基本不用。

调度策略 特点 适用场景
SCHED_FIFO 先入先出，不抢占同优先级 短任务、中断处理
SCHED_RR 时间片轮转，同优先级轮流执行 多个同等重要的周期性任务
SCHED_SPORADIC 偶发调度，适合低带宽高优先级任务 事件驱动型任务

你想想看，如果你有两个线程做同样的数据处理，用FIFO的话，第一个线程不跑完第二个就永远没机会。这时候就该用RR。我曾经在ADAS项目中，把摄像头数据采集线程设成FIFO，图像处理线程设成RR，结果采集线程优先级太高，处理线程拿不到CPU。后来调整了一下，把采集线程优先级降低，用RR调度，问题就解决了。

小技巧：如果你不确定用哪种策略，先用SCHED_RR。它最安全，不容易出现线程饿死的情况。等性能调优时再根据实际需求调整。

3.3 优先级管理：别让高优先级线程饿死低优先级

QNX的优先级范围是0到255，数字越大优先级越高。但注意，0是空闲线程，255是最高优先级（通常留给内核）。用户线程一般用1到254。

设置优先级用pthread_setschedparam()：

struct sched_param param;
param.sched_priority = 30;  // 中等优先级
pthread_setschedparam(thread_id, SCHED_RR, &param);

这里有个坑——优先级反转。低优先级线程拿着锁，高优先级线程等着锁，中间还有个中优先级线程抢占了CPU。结果高优先级线程被低优先级线程阻塞，而低优先级又跑不过中优先级。嗯，这就是经典的优先级反转问题。

我当年在工控项目里就遇到过。一个高优先级的报警线程被一个低优先级的日志线程阻塞，中间还有个网络线程在疯狂发包。报警延迟了整整200毫秒，差点出事故。后来我们用优先级继承协议解决了这个问题。

核心原则：优先级不是越高越好。高优先级线程应该只做短小精悍的工作。如果它要长时间占用CPU，反而会拖垮整个系统。

3.4 同步与互斥：Mutex和Condvar的正确用法

先说Mutex。QNX的pthread_mutex_t支持多种类型：普通锁、递归锁、错误检查锁。我建议在嵌入式系统里用PTHREAD_MUTEX_RECURSIVE，因为有时候一个函数内部会多次加锁，递归锁不会死锁。

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void safe_write(int data) {
    pthread_mutex_lock(&mutex);
    // 写共享数据
    pthread_mutex_unlock(&mutex);
}

但Mutex有个问题——它只能解决互斥，不能解决等待条件。比如一个线程要等数据准备好，用Mutex就得轮询，浪费CPU。这时候就该Condvar上场了。

Condvar（条件变量）配合Mutex使用，可以让线程在条件不满足时休眠，条件满足时被唤醒。来看个典型的生产者-消费者模式：

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int data_ready = 0;

// 消费者线程
void *consumer(void *arg) {
    pthread_mutex_lock(&mutex);
    while (!data_ready) {
        pthread_cond_wait(&cond, &mutex);  // 自动释放锁并休眠
    }
    // 处理数据
    data_ready = 0;
    pthread_mutex_unlock(&mutex);
    return NULL;
}

// 生产者线程
void *producer(void *arg) {
    pthread_mutex_lock(&mutex);
    // 生产数据
    data_ready = 1;
    pthread_cond_signal(&cond);  // 唤醒消费者
    pthread_mutex_unlock(&mutex);
    return NULL;
}

注意，pthread_cond_wait()必须在循环里调用。为什么？因为可能有虚假唤醒。我在项目中遇到过，一个线程被唤醒了但条件还没满足，结果读了脏数据。后来加上while循环，问题就解决了。

避坑指南：我曾经在Condvar里犯过一个低级错误——在加锁之前调用了pthread_cond_signal()。结果信号丢失了，消费者线程永远等不到唤醒。记住，一定要在锁的保护下操作条件变量。

3.5 实战建议：如何设计一个稳定的多线程系统

说了这么多，最后给几个实战建议：

  1. 线程数量要控制。不是越多越好。我一般一个CPU核心跑2-3个活跃线程就够了。太多线程会导致上下文切换开销过大。
  2. 优先级要分层。把任务分成高、中、低三层。高优先级做实时响应，中优先级做常规处理，低优先级做后台任务。
  3. 锁的粒度要细。别一把大锁锁住所有资源。尽量用读写锁（pthread_rwlock_t）来优化读多写少的场景。
  4. 用工具检测死锁。QNX自带的pidin命令可以查看线程状态。如果发现线程卡在MUTEX状态，多半是死锁了。

嗯，这一章的内容就到这里。进程和线程管理是QNX开发的基石，搞懂了这些，后面的消息传递和中断处理就会轻松很多。下一章咱们聊QNX最引以为傲的消息传递机制，那可是微内核的精髓所在。

← 上一章 📖 返回目录 下一章 →