📚 课程目录第2章进程间通信(IPC)基础

进程间通信(IPC)基础：消息传递的核心机制

说到QNX，绕不开的就是IPC。我经常跟团队里的新人讲，QNX的IPC就是整个系统的血脉。你想想看，一个微内核系统，所有服务都在独立的进程里跑，它们之间怎么协作？靠的就是消息传递。

这一节，咱们就深入聊聊消息传递的核心机制。我会结合自己这些年踩过的坑，把Channel和Connection的建立、同步异步模型这些关键点讲透。

消息传递：QNX IPC的基石

QNX的消息传递，说白了就是进程之间互相发数据。但跟Linux的信号、共享内存不一样，QNX的消息传递是带语义的——它不光传数据，还传递了控制流。

核心概念：在QNX中，消息传递是同步的、带优先级的、有类型检查的。发送方和接收方通过Channel和Connection建立通信链路。

我记得第一次用QNX做多核项目时，有个同事问：“为什么不用共享内存？多快啊。”我告诉他：“共享内存快是快，但你得自己处理同步、互斥、优先级反转。消息传递把这些都封装好了，你只管发和收就行。”

Channel与Connection：通信的两端

消息传递需要两个基本构件：Channel（通道）和Connection（连接）。

Channel：接收端创建的通信端点。一个进程可以创建多个Channel，每个Channel有唯一的ID。
Connection：发送端与Channel建立的连接。一个Connection关联一个Channel，发送方通过Connection发送消息。

你可以把Channel想象成门牌号，Connection就是通往这个门牌号的专线。接收方挂出牌子（创建Channel），发送方拨号（建立Connection），然后开始通话（收发消息）。

创建Channel

#include <sys/neutrino.h>

int chid;
chid = ChannelCreate(0);  // 创建默认属性的Channel
if (chid == -1) {
    // 处理错误
}

这里有个细节：ChannelCreate的参数是标志位，可以控制Channel的行为。比如加上_NTO_CHF_FIXED_PRIORITY，接收线程的优先级就不会被发送方影响。我在做实时控制项目时经常用这个标志，确保高优先级任务不被低优先级消息干扰。

建立Connection

int coid;
coid = ConnectAttach(0, pid, chid, 0, 0);
if (coid == -1) {
    // 处理错误
}

ConnectAttach的参数依次是：节点描述符（0表示本地节点）、目标进程PID、目标Channel ID、索引（通常为0）、标志位。

个人经验：我建议在建立Connection后，用ConnectDetach在不需要时释放。曾经有个项目因为忘记释放Connection，导致系统资源耗尽，排查了好久才发现是连接泄漏。

同步消息传递：最常用的模式

QNX的同步消息传递，是阻塞式的。发送方调用MsgSend后，会一直等待，直到接收方处理完并回复。接收方调用MsgReceive等待消息，处理完后用MsgReply回复。

这个流程可以用下面的图来表示：

看明白了吗？发送方发出消息后，自己就挂起了。接收方收到消息，处理完，回复。发送方收到回复后，才继续往下走。

代码示例：

// 发送方
char send_msg[] = "Hello QNX";
char reply_msg[64];
int status;

status = MsgSend(coid, send_msg, strlen(send_msg)+1, 
                 reply_msg, sizeof(reply_msg));
if (status == -1) {
    // 处理错误
}

// 接收方
char recv_msg[64];
char reply_msg[] = "Reply from server";
int rcvid;

rcvid = MsgReceive(chid, recv_msg, sizeof(recv_msg), NULL);
// 处理消息...
MsgReply(rcvid, 0, reply_msg, strlen(reply_msg)+1);

注意：MsgSend的阻塞不是忙等，而是让出CPU。发送方进程进入等待状态，调度器会运行其他就绪进程。这才是实时系统的精髓——不浪费CPU轮询。

异步消息传递：什么时候用？

同步模型虽然简单可靠，但有时候发送方不想等。比如一个监控进程，每秒发一次状态更新，如果接收方处理慢了，发送方就被拖住了。

这时候可以用异步消息传递。QNX提供了两种方式：

方式	API	行为	适用场景
非阻塞发送	`MsgSendnc()`	发送后立即返回，不等待回复	状态更新、心跳、日志
脉冲消息	`MsgSendPulse()`	发送小数据（最多4字节），非阻塞	中断通知、事件触发

MsgSendnc的用法跟MsgSend几乎一样，只是不阻塞：

int status;
status = MsgSendnc(coid, send_msg, strlen(send_msg)+1, 
                   reply_msg, sizeof(reply_msg));
if (status == -1) {
    // 处理错误
}
// 这里立即执行，不等回复

但要注意：MsgSendnc虽然不阻塞，但接收方仍然可以用MsgReply回复。发送方需要自己检查是否有回复。我一般用MsgReceive配合MsgSendnc来实现半同步模式。

脉冲消息：轻量级通知

脉冲消息是QNX的特色。它只能携带一个8位代码和最多4字节数据，但开销极小。我在做中断处理时特别喜欢用脉冲——中断服务程序里不能阻塞，发个脉冲通知用户态进程，完美。

// 发送脉冲
struct _pulse pulse;
pulse.code = _PULSE_CODE_MINAVAIL + 1;  // 自定义代码
pulse.value.sival_int = 42;             // 附带数据

int status = MsgSendPulse(coid, sched_get_priority_min(SCHED_RR), 
                          pulse.code, pulse.value);
if (status == -1) {
    // 处理错误
}

// 接收脉冲（与普通消息共用同一个Channel）
struct _msg_info info;
char buffer[256];
int rcvid = MsgReceive(chid, buffer, sizeof(buffer), &info);
if (rcvid == 0) {
    // 收到的是脉冲
    struct _pulse *pulse = (struct _pulse *)buffer;
    // 处理脉冲...
}

避坑指南：我曾经在接收端忘记判断rcvid == 0，直接把脉冲当普通消息处理，结果MsgReply返回错误。记住：脉冲的rcvid是0，普通消息的rcvid是正数。

同步 vs 异步：怎么选？

我总结了一个简单的选择原则：

需要确认：用同步。比如客户端请求服务器执行操作，必须知道结果。
不需要确认：用异步。比如日志、状态上报、心跳。
实时性要求高：用脉冲。比如中断通知、紧急事件。

但别走极端。我见过有人把所有通信都做成异步，结果系统里到处都是轮询和超时处理，代码复杂度翻倍。同步模型虽然简单，但能解决80%的问题。

Channel与Connection的生命周期

最后聊聊生命周期管理。Channel和Connection都是系统资源，用完后必须释放。

操作	API	说明
创建Channel	`ChannelCreate()`	返回chid，失败返回-1
销毁Channel	`ChannelDestroy(chid)`	释放所有关联的Connection
建立Connection	`ConnectAttach()`	返回coid，失败返回-1
断开Connection	`ConnectDetach(coid)`	只断开，不影响Channel

有个细节：ChannelDestroy会强制断开所有关联的Connection。如果接收进程崩溃了，发送方再发消息会收到错误。我在做高可用系统时，会监听进程退出事件，主动重连。

资源泄漏警告：每个进程能创建的Channel和Connection数量是有限的。默认情况下，RLIMIT_NUM_CHANNELS和RLIMIT_NUM_CONNECTIONS有上限。我曾经在生产环境遇到过因为连接泄漏导致ConnectAttach返回ENOMEM的故障。

嗯，消息传递的基础就这些。Channel和Connection是骨架，同步异步是血肉，脉冲消息是神经末梢。把这些搞清楚了，QNX IPC的大门就向你敞开了。