第4章：QNX进程间通信（IPC）——消息传递、共享内存、管道、信号

进程间通信，简称IPC，是QNX系统的灵魂。说实话，没有IPC，QNX就不叫QNX了。我刚开始接触QNX时，最震撼的就是它的消息传递机制——别的RTOS还在用全局变量传数据，QNX已经用微内核架构把各个模块拆得干干净净，再用IPC把它们粘起来。

这一章，我们聊聊QNX里最常用的四种IPC方式：消息传递、共享内存、管道和信号。每种方式都有它的脾气，选对了事半功倍，选错了……嗯，我在项目里踩过不少坑，后面会一一说到。

4.1 消息传递（Message Passing）——QNX的看家本领

消息传递是QNX IPC的核心。别的系统可能把消息传递当成一种可选方案，但在QNX里，它是默认选项。你想想看，QNX的微内核架构里，驱动、文件系统、协议栈全都是独立的进程，它们之间怎么通信？靠的就是消息传递。

消息传递有两种模式：同步和异步。同步模式最常用，发送方会阻塞直到接收方处理完消息并回复。异步模式则允许发送方发完就走，不等待回复。

核心API：

  • Send() — 发送消息并等待回复（同步）
  • Receive() — 接收消息
  • Reply() — 回复消息
  • MsgSend() / MsgReceive() / MsgReply() — POSIX风格的变体

来看一个简单的例子。假设我们有一个传感器进程和一个控制进程，传感器采集数据，控制进程处理数据：

// 传感器进程（发送方）
#include <sys/neutrino.h>
#include <stdio.h>

typedef struct {
    int sensor_id;
    float temperature;
    float pressure;
} sensor_data_t;

int main() {
    int coid;  // 连接ID
    sensor_data_t data = {1, 25.6, 1013.2};
    char reply[64];

    // 连接到控制进程的通道
    coid = ConnectAttach(0, 0, 1, _NTO_SIDE_CHANNEL, 0);
    if (coid == -1) {
        perror("ConnectAttach failed");
        return 1;
    }

    // 发送数据并等待回复
    if (MsgSend(coid, &data, sizeof(data), reply, sizeof(reply)) == -1) {
        perror("MsgSend failed");
    } else {
        printf("控制进程回复: %s\n", reply);
    }

    ConnectDetach(coid);
    return 0;
}

// 控制进程（接收方）
#include <sys/neutrino.h>
#include <stdio.h>

typedef struct {
    int sensor_id;
    float temperature;
    float pressure;
} sensor_data_t;

int main() {
    int chid;  // 通道ID
    sensor_data_t data;
    int rcvid;

    // 创建通道
    chid = ChannelCreate(0);
    if (chid == -1) {
        perror("ChannelCreate failed");
        return 1;
    }

    printf("通道创建成功，ID: %d\n", chid);

    while (1) {
        // 接收消息
        rcvid = MsgReceive(chid, &data, sizeof(data), NULL);
        if (rcvid == -1) {
            perror("MsgReceive failed");
            continue;
        }

        printf("收到传感器%d数据: 温度=%.1f, 气压=%.1f\n",
               data.sensor_id, data.temperature, data.pressure);

        // 回复消息
        MsgReply(rcvid, 0, "数据已接收", 12);
    }

    return 0;
}

我的经验：消息传递的同步特性其实是个双刃剑。好处是天然实现了流控——发送方不会比接收方快太多。坏处是如果接收方处理慢了，发送方会一直阻塞。我在做车载诊断模块时，就遇到过接收方死锁导致所有发送方全部挂起的惨案。后来我加了个超时机制，用MsgSendPulse()发脉冲消息做心跳检测，才解决了这个问题。

4.2 共享内存（Shared Memory）——大块数据的搬运工

消息传递虽然好用，但每次都要拷贝数据。如果你要传的是摄像头的一帧图像，或者激光雷达的点云数据，每次拷贝几兆甚至几十兆，那性能就扛不住了。这时候，共享内存就派上用场了。

共享内存的原理很简单：两个或多个进程映射同一块物理内存。一个进程写，另一个进程读，数据不需要拷贝。但问题来了——怎么保证读写同步？

QNX里，共享内存通常配合同步原语一起用。最常用的组合是：shm_open() + mmap() + 互斥锁或信号量。

// 共享内存示例：生产者-消费者模式
#include <sys/mman.h>
#include <fcntl.h>
#include <semaphore.h>
#include <unistd.h>
#include <stdio.h>

#define SHM_NAME "/my_shared_mem"
#define BUFFER_SIZE 1024

typedef struct {
    sem_t sem_producer;
    sem_t sem_consumer;
    char data[BUFFER_SIZE];
    int data_ready;
} shared_data_t;

// 生产者进程
int main() {
    int fd;
    shared_data_t *shared;

    // 创建共享内存对象
    fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
    ftruncate(fd, sizeof(shared_data_t));

    // 映射到进程地址空间
    shared = mmap(NULL, sizeof(shared_data_t),
                  PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

    // 初始化信号量
    sem_init(&shared->sem_producer, 1, 1);
    sem_init(&shared->sem_consumer, 1, 0);

    while (1) {
        sem_wait(&shared->sem_producer);

        // 写入数据
        sprintf(shared->data, "时间戳: %ld", time(NULL));
        shared->data_ready = 1;
        printf("生产者写入: %s\n", shared->data);

        sem_post(&shared->sem_consumer);
        sleep(1);
    }

    munmap(shared, sizeof(shared_data_t));
    return 0;
}

注意：共享内存虽然快，但调试起来很痛苦。我曾经在项目里遇到一个bug：两个进程通过共享内存传数据，偶尔会出现数据错乱。查了两天才发现，是信号量初始化时第二个参数写成了0（进程内共享），而不是1（进程间共享）。这种错误编译器不会报错，运行时也不一定每次都触发，特别隐蔽。

4.3 管道（Pipe）——简单场景的利器

管道是最古老的IPC方式之一，QNX当然也支持。管道分两种：匿名管道和命名管道（FIFO）。

匿名管道通常用于父子进程之间。父进程创建管道，fork出子进程，然后一个写一个读。命名管道则没有这个限制，任意两个进程都可以通过路径名来通信。

我个人觉得，管道最适合的场景是：数据流是单向的，而且数据量不大。比如日志输出、简单的命令传递。

// 命名管道示例
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>

#define FIFO_PATH "/tmp/diag_fifo"

// 写入端
int main() {
    int fd;
    char msg[] = "诊断请求: 读取DTC";

    // 创建命名管道
    mkfifo(FIFO_PATH, 0666);

    fd = open(FIFO_PATH, O_WRONLY);
    write(fd, msg, sizeof(msg));
    close(fd);

    return 0;
}

// 读取端
int main() {
    int fd;
    char buf[256];

    fd = open(FIFO_PATH, O_RDONLY);
    read(fd, buf, sizeof(buf));
    printf("收到: %s\n", buf);
    close(fd);

    unlink(FIFO_PATH);  // 删除管道文件
    return 0;
}

避坑指南：我曾经在诊断工具里用命名管道传UDS诊断数据，结果发现如果读取端还没打开管道，写入端open()会阻塞。这在调试时没问题，但到了实车上，诊断仪一启动就卡住了。后来我改用O_NONBLOCK标志，或者先启动读取端再启动写入端，才解决了这个问题。

4.4 信号（Signal）——轻量级的通知机制

信号是QNX里最轻量的IPC方式。它不传数据，只传一个信号编号。你可以把信号理解成一种「软中断」——进程收到信号后，会中断当前执行，去处理信号处理函数。

QNX支持标准的POSIX信号，比如SIGINT、SIGTERM、SIGKILL，也支持实时信号SIGRTMIN到SIGRTMAX。实时信号可以附带一个整数值，算是带了点数据。

信号适合做什么？

  • 通知进程退出或重启
  • 触发某个紧急操作（比如看门狗超时）
  • 简单的状态变化通知

但信号不适合做什么？

  • 传递大量数据
  • 需要可靠传输的场景（信号可能会丢失）
  • 复杂的同步逻辑
// 信号处理示例
#include <signal.h>
#include <stdio.h>
#include <unistd.h>

volatile sig_atomic_t g_quit_flag = 0;

void signal_handler(int sig) {
    if (sig == SIGTERM) {
        g_quit_flag = 1;
        printf("收到SIGTERM，准备退出...\n");
    } else if (sig == SIGUSR1) {
        printf("收到SIGUSR1，执行诊断任务...\n");
    }
}

int main() {
    // 注册信号处理函数
    signal(SIGTERM, signal_handler);
    signal(SIGUSR1, signal_handler);

    printf("进程启动，PID: %d\n", getpid());

    while (!g_quit_flag) {
        // 正常业务逻辑
        sleep(1);
    }

    printf("进程退出\n");
    return 0;
}

重要提醒：信号处理函数里能做的事情非常有限。你不能在信号处理函数里调用printf、malloc这些非重入函数。我见过有人直接在信号处理函数里写日志，结果程序随机崩溃，查了好久才发现是信号处理函数里调用了非线程安全的函数。正确的做法是：信号处理函数里只设置一个标志位，然后在主循环里检查这个标志位。

4.5 如何选择？一张表说清楚

说了这么多，到底该用哪种IPC？我整理了一张表，你直接对照着选就行：

IPC方式 数据量 传输方向 同步方式 典型场景
消息传递 小到中等（通常<64KB） 双向 同步（默认） 客户端-服务器、RPC调用
共享内存 大（几MB到几百MB） 双向 需要外部同步 图像数据、传感器数据流
管道 小到中等 单向 阻塞式 日志、简单命令传递
信号 几乎无数据 单向 异步 退出通知、紧急事件

我的建议：如果你不确定选哪个，默认用消息传递。QNX的消息传递经过了几十年的工业验证，稳定性和性能都很好。只有当你明确遇到性能瓶颈时，才考虑换成共享内存。至于管道和信号，它们有特定的适用场景，不要滥用。

4.6 实战中的坑与经验

最后分享几个我在车机诊断项目中遇到的真实案例：

  1. 消息传递的优先级反转：高优先级进程发送消息给低优先级进程，结果低优先级进程被其他中等优先级进程抢占，高优先级进程反而被阻塞。解决方案是用ChannelCreate()的优先级继承属性。
  2. 共享内存的缓存一致性问题：在ARM多核平台上，两个核通过共享内存传数据，一个核写完了，另一个核读到的却是旧数据。这是因为CPU缓存没有刷新。解决方案是用内存屏障指令，或者用QNX的msync()函数。
  3. 管道的死锁：两个进程互相通过管道通信，结果都阻塞在read()上，形成了死锁。解决方案是改用消息传递，或者用非阻塞I/O加select()轮询。

嗯，IPC这块内容就这么多。记住一句话：没有最好的IPC，只有最合适的IPC。下一章我们聊聊QNX的中断处理，那可是实时系统的核心能力。

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