3. QNX进程与线程管理：进程创建与销毁、线程调度策略、优先级反转与解决、同步原语

好，咱们今天聊点硬核的。进程与线程管理，这是QNX实时系统的核心骨架。我做了这么多年工业控制器，可以负责任地告诉你——这部分要是搞不明白，后面写出来的代码大概率会在现场出幺蛾子。

3.1 进程创建与销毁：别小看fork()和spawn()

在QNX里创建进程，最直接的方式是fork()。但说实话，我在工业现场很少直接用fork。为什么？因为fork会复制整个地址空间，对于实时系统来说，这个开销太大了。

我个人习惯用spawn()或者posix_spawn()。它们更轻量，而且可以精确控制子进程的优先级、调度策略、甚至绑定的CPU核心。

// 我常用的 spawn 示例
pid_t pid;
struct inheritance inherit;

inherit.flags = SPAWN_SETPARAM;
inherit.prio = 30;  // 设定优先级
inherit.sched = SCHED_FIFO;  // FIFO调度

pid = spawn("control_task", 0, NULL, &inherit, NULL, NULL);
if (pid == -1) {
    // 嗯，这里要处理错误
    perror("spawn failed");
}

销毁进程呢？kill(pid, SIGTERM)是标准做法。但我踩过一个坑——子进程可能正握着共享内存的锁。直接kill会导致资源泄漏。所以我一般先发一个自定义信号，让子进程自己清理退出。

注意：我曾经在一条产线上遇到过，直接kill掉一个持有Mutex的进程，结果导致整个系统死锁。从那以后，我强制团队所有进程退出必须走“优雅关闭”流程。

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

QNX支持三种实时调度策略。你想想看，选错了策略，控制器响应时间可能差一个数量级。

策略特点适用场景
SCHED_FIFO先到先服务，直到主动让出或被抢占紧急任务，如急停处理
SCHED_RR时间片轮转，同优先级轮流执行多个同等重要的周期性任务
SCHED_SPORADIC偶发调度，限制高优先级任务的执行时间偶发但紧急的事件处理

FIFO调度：说白了就是“谁先来谁先跑，跑完才让位”。我做过一个伺服驱动器，位置环线程用FIFO，优先级设到最高。因为它必须立刻响应编码器中断，一秒都不能等。

RR调度：每个线程跑一个时间片，然后换下一个。适合那些“大家都差不多重要”的场景。比如多个传感器数据采集线程，用RR就挺合适。

SPORADIC调度：这个比较特殊。它允许一个线程在短时间内“爆发”到高优先级，但有一个预算限制。预算用完了，优先级就降下来。我在项目中遇到过一种情况——一个报警处理线程，平时不干活，但一旦触发必须立刻处理。用SPORADIC正好，既保证了紧急响应，又不会饿死其他线程。

我的经验：别把所有线程都设成FIFO最高优先级。你想想看，如果三个高优先级FIFO线程互相抢CPU，低优先级的看门狗线程就永远跑不起来了。系统迟早会挂。

3.3 优先级反转与解决：一个血泪史

优先级反转，这是实时系统的经典坑。我当年刚入行时，就在一个运动控制器上栽过跟头。

场景是这样的：
- 高优先级线程A（控制计算）
- 中优先级线程B（日志记录）
- 低优先级线程C（共享资源持有者）

A要访问C持有的资源，于是被阻塞。C开始运行，但B抢占了C。结果呢？A在等C，C被B抢了，B在那慢慢写日志。A明明优先级最高，却被两个低优先级线程“反转”了。

解决方式有三种：

  1. 优先级继承：当高优先级线程等待低优先级线程持有的锁时，低优先级线程临时“继承”高优先级。这是QNX Mutex默认的行为。
  2. 优先级天花板：给每个资源设定一个天花板优先级。任何线程持有该资源时，优先级自动提升到天花板。
  3. 关中断：最粗暴的方式，但只适合极短的操作。
// QNX Mutex默认启用优先级继承
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);  // 继承协议

pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr);
关键点：我曾经调试过一个间歇性卡顿的问题，查了三天才发现是Mutex没设优先级继承。加上这一行代码，问题立刻消失。嗯，有时候解决问题就这么简单。

3.4 同步原语：Mutex、Condvar、Semaphore

这三个东西，是线程间通信的基石。但用法完全不同，别搞混了。

Mutex（互斥锁）

保护共享资源用的。谁拿到锁，谁就能访问数据。其他人等着。

pthread_mutex_lock(&mutex);
// 操作共享数据
shared_counter++;
pthread_mutex_unlock(&mutex);

注意：Mutex的加锁和解锁必须在同一个线程。我见过有人在一个线程里lock，另一个线程里unlock——这是未定义行为，千万别这么干。

Condvar（条件变量）

用于“等待某个条件成立”。比如：生产者线程生产数据，消费者线程等待数据。

// 消费者线程
pthread_mutex_lock(&mutex);
while (queue_empty()) {
    pthread_cond_wait(&cond, &mutex);  // 等待条件
}
data = dequeue();
pthread_mutex_unlock(&mutex);

// 生产者线程
pthread_mutex_lock(&mutex);
enqueue(new_data);
pthread_cond_signal(&cond);  // 唤醒消费者
pthread_mutex_unlock(&mutex);

这里有个细节：pthread_cond_wait返回时，一定要用while循环检查条件。为什么？因为可能有“虚假唤醒”。我在项目中遇到过，加了while之后，系统稳定性明显提升。

Semaphore（信号量）

信号量更像一个计数器。用于“资源可用数量”的管理。比如：一个缓冲池有10个缓冲区，用信号量来计数。

sem_t sem;
sem_init(&sem, 0, 10);  // 初始10个资源

// 获取资源
sem_wait(&sem);
// 使用缓冲区...
// 释放资源
sem_post(&sem);

信号量和Mutex的区别？Mutex是“谁拥有谁释放”，信号量是“谁都可以post”。所以信号量更适合“生产者-消费者”模型，而Mutex更适合“保护共享数据”。

避坑指南：我曾经在一个多线程项目中，用Mutex来实现“等待事件”的功能。结果代码又臭又长，还容易死锁。后来换成Condvar，代码量减少一半，逻辑也清晰多了。选对同步原语，比什么都重要。

好了，这一章的内容就这些。进程创建、线程调度、优先级反转、同步原语——这四个点吃透了，QNX的多线程编程你就入门了。下一章我们聊聊中断处理与时钟管理，那又是另一个有意思的话题。

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