4. IPC通信机制：消息传递、共享内存、Pulse信号、Proxy机制
说到QNX的IPC，我得先坦白一件事。
我刚入行那会儿，总觉得IPC不就是进程间传数据嘛，Linux上搞个socket或者pipe不就完了？直到我第一次在车机上遇到一个诡异问题——导航语音播报和音乐播放抢声道，声音断断续续。查了三天，最后发现是IPC通信延迟导致的优先级反转。
嗯，从那以后，我再也不敢小看QNX的IPC机制了。
4.1 消息传递——QNX的"亲儿子"
消息传递是QNX最核心的IPC方式。说白了，它就是进程之间互相发消息，但QNX把它做得特别"硬实时"。
我个人习惯把消息传递分成两种场景：
- 同步消息：发送方发完就等着，接收方处理完才返回。适合"你问我答"的场景。
- 异步消息：发完就走，不等待回复。适合"通知一声"的场景。
举个例子，我在做车载中控的空调控制模块时，温度调节按钮按下后，UI进程需要告诉空调控制进程"把温度调到24度"。
// 发送方（UI进程）
int chid = ConnectAttach(0, pid, 0, _NTO_SIDE_CHANNEL, 0);
MsgSend(chid, "SET_TEMP=24", 12, reply, sizeof(reply));
// 接收方（空调控制进程）
int rcvid = MsgReceive(chid, msg, sizeof(msg), NULL);
// 解析消息，执行调温操作
MsgReply(rcvid, EOK, "OK", 3);
这里有个坑，我踩过——MsgSend是阻塞的。如果你在UI线程里直接发消息，而接收方处理慢了，UI就会卡住。所以，我建议把耗时IPC放到工作线程里做。
4.2 共享内存——速度最快的IPC
如果你需要传大量数据，比如摄像头图像、音频流，消息传递就不太合适了。这时候，共享内存是首选。
共享内存的原理很简单：两个进程把同一块物理内存映射到各自的虚拟地址空间。读写就像操作本地变量一样快。
但问题来了——怎么保证数据一致性？
我一般配合互斥锁或者信号量来用。举个例子，我在做360环视系统时，摄像头采集进程把图像数据写入共享内存，显示进程从中读取。
// 创建共享内存
int fd = shm_open("/camera_frame", O_RDWR | O_CREAT, 0666);
ftruncate(fd, FRAME_SIZE);
void *addr = mmap(NULL, FRAME_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 写入数据（采集进程）
pthread_mutex_lock(&mtx);
memcpy(addr, frame_data, FRAME_SIZE);
pthread_mutex_unlock(&mtx);
// 读取数据（显示进程）
pthread_mutex_lock(&mtx);
memcpy(local_buffer, addr, FRAME_SIZE);
pthread_mutex_unlock(&mtx);
4.3 Pulse信号——轻量级的"敲门砖"
Pulse信号，你可以把它理解成一种"迷你消息"。它只有40字节的负载，但发送开销极低，而且是非阻塞的。
什么时候用Pulse？
- 通知事件发生，比如"按键被按下"
- 触发定时器回调
- 中断服务程序向用户态进程发信号
我记得有一次做车载蓝牙模块，蓝牙芯片的中断需要通知应用层"有数据来了"。如果用消息传递，中断上下文里不能阻塞，用Pulse就刚刚好。
// 发送Pulse
struct _pulse pulse;
pulse.code = _PULSE_CODE_MINAVAIL + 1;
pulse.value.sival_int = 42; // 携带一个整数值
MsgSendPulse(coid, sched_priority, pulse.code, pulse.value);
// 接收Pulse
MsgReceive(chid, &msg, sizeof(msg), NULL);
if (msg.hdr.type == _IO_BASE && msg.hdr.subtype == _IO_PULSE) {
// 处理Pulse
int value = msg.pulse.value.sival_int;
}
嗯，这里要注意：Pulse的负载很小，只能带一个整数或者一个指针。如果你需要传复杂结构，还是用消息传递吧。
4.4 Proxy机制——"远程调用"的优雅实现
Proxy机制，说白了就是让一个进程可以"代理"另一个进程执行操作。它基于消息传递，但封装得更高级。
我最早接触Proxy是在做车载语音助手时。语音识别进程需要调用TTS（文本转语音）进程来播报结果。如果用原始的消息传递，我得自己处理请求路由、超时重试等逻辑。用Proxy就省事多了。
Proxy的工作流程大致是：
- 服务端注册一个"代理函数"
- 客户端通过代理函数发起调用
- 底层自动完成消息的发送和接收
// 服务端注册代理
int proxy_id = ProxyCreate(proxy_func, NULL);
// 客户端调用代理
int result = ProxyCall(proxy_id, arg1, arg2);
4.5 如何选择？——我的实战经验
很多初学者会问：这么多IPC方式，到底该用哪个？
我一般按这个原则来选：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 小数据、请求-响应 | 消息传递 | 简单可靠，QNX原生支持 |
| 大数据、高频读写 | 共享内存 | 性能最优，零拷贝 |
| 事件通知、中断处理 | Pulse信号 | 非阻塞，开销极小 |
| 远程调用、模块解耦 | Proxy机制 | 代码优雅，易于维护 |
我曾经在一个项目中同时用了三种IPC方式：CAN总线数据用Pulse通知应用层，导航地图数据用共享内存传输，空调控制用消息传递做请求响应。各司其职，系统跑得很稳。
最后说一句：IPC的选择没有银弹。你得根据实际场景、数据量、实时性要求来权衡。多测试，多踩坑，慢慢就有感觉了。