一、脉冲（Pulse）机制：轻量级的进程间通信
脉冲机制，说白了就是QNX里一种“短平快”的通信方式。它不像消息那样要来回传递数据，而是只发送一个40字节的小数据包。我刚开始接触QNX时，总觉得脉冲和消息差不多，后来踩过坑才明白——这两者完全是两码事。
1.1 什么是脉冲
脉冲是一种非阻塞的、单向的进程间通信机制。发送方发完脉冲就走，不需要等待接收方处理。接收方呢？它会在自己的通道上收到一个优先级较高的通知。
脉冲的结构很简单：
- 代码（code）：一个8位的整数，用来标识脉冲类型
- 值（value）：一个32位的整数，携带具体数据
- 优先级（priority）：脉冲本身的优先级，影响接收顺序
嗯，这里要注意：脉冲总共就40字节，别想着塞大数据进去。我见过有人试图在脉冲里传结构体，结果数据被截断了——这种坑我踩过一次就记住了。
2.2 脉冲与消息的区别
很多初学者会把脉冲和消息搞混。我列个表格，你一看就明白：
| 特性 | 脉冲（Pulse） | 消息（Message） |
|---|---|---|
| 通信方向 | 单向（发送方→接收方） | 双向（发送→接收→回复） |
| 阻塞行为 | 非阻塞，发送后立即返回 | 阻塞，等待接收方回复 |
| 数据大小 | 固定40字节（8位code + 32位value） | 任意大小（通过指针传递） |
| 优先级 | 自带优先级，可影响调度 | 无独立优先级，依赖发送线程 |
| 典型用途 | 中断通知、定时器、状态变化 | 请求-响应、数据传输 |
为什么会这样设计？你想想看，中断处理程序里能阻塞吗？绝对不能！中断上下文里你连malloc都不敢调，更别说等消息回复了。脉冲就是为这种场景量身定做的。
3.3 脉冲的使用场景
我个人习惯把脉冲用在三个地方：中断通知、定时器、以及状态变化通知。下面逐个说。
3.3.1 中断通知
这是脉冲最经典的应用。硬件中断来了，ISR（中断服务程序）里不能做复杂操作，那就发个脉冲通知某个线程去处理。
我记得在做一个数据采集项目时，ADC每10微秒产生一次中断。ISR里如果直接处理数据，系统响应时间根本跟不上。后来我用脉冲把中断事件通知给一个高优先级线程，由它批量处理数据——问题迎刃而解。
代码示例：
// 中断服务程序中的脉冲发送
const struct sigevent *interrupt_handler(void *area, int id) {
// 发送脉冲给接收通道
MsgSendPulse(channel_id, SIGEV_PULSE_PRIO_INHERIT,
PULSE_CODE_INTERRUPT, 0);
return NULL;
}
// 接收线程
int receive_pulse() {
struct _pulse pulse;
while(1) {
// 接收脉冲（阻塞等待）
MsgReceive(channel_id, &pulse, sizeof(pulse), NULL);
if(pulse.code == PULSE_CODE_INTERRUPT) {
// 处理中断数据
process_adc_data();
}
}
}3.3.2 定时器
定时器到期后，系统会发送一个脉冲给指定线程。这是QNX里实现周期性任务的标配做法。
你想想看，如果用消息来实现定时通知，那接收方还得回复，多此一举。脉冲就干净利落——定时器到期，发个脉冲，线程收到后执行任务，完事。
代码示例：
// 创建定时器并关联脉冲
timer_t timer_id;
struct sigevent event;
struct itimerspec spec;
// 配置脉冲事件
event.sigev_notify = SIGEV_PULSE;
event.sigev_coid = channel_id; // 接收通道
event.sigev_code = PULSE_CODE_TIMER;
event.sigev_value.sival_int = 0;
// 创建定时器
timer_create(CLOCK_REALTIME, &event, &timer_id);
// 设置周期为100ms
spec.it_value.tv_sec = 0;
spec.it_value.tv_nsec = 100000000;
spec.it_interval.tv_sec = 0;
spec.it_interval.tv_nsec = 100000000;
timer_settime(timer_id, 0, &spec, NULL);
// 接收线程中处理定时脉冲
struct _pulse pulse;
MsgReceive(channel_id, &pulse, sizeof(pulse), NULL);
if(pulse.code == PULSE_CODE_TIMER) {
// 执行周期性任务
do_periodic_work();
}3.3.3 状态变化通知
除了中断和定时器，脉冲还常用于通知状态变化。比如：
- 设备驱动检测到硬件插拔
- 网络连接状态变化
- 缓冲区从空变为非空
这些场景的共同特点是：通知方不需要等待回复，接收方知道发生了什么就行。脉冲的40字节足够传递状态码和附加信息了。
举个例子，我在做车载系统时，用脉冲通知各个模块“电源状态变化”。每个模块收到脉冲后，各自做自己的处理——有的保存数据，有的关闭外设，有的只是记录日志。大家互不干扰，各干各的。
4.4 脉冲的优先级行为
嗯，这里有个细节很多人会忽略：脉冲是有优先级的。发送脉冲时，你可以指定优先级，接收方会按优先级顺序处理脉冲。
我记得有一次调试，发现高优先级的中断脉冲总是被低优先级的定时器脉冲“插队”。后来查文档才明白——脉冲的优先级是独立于线程优先级的。如果你不显式设置，默认会继承发送方的优先级。
建议做法：
- 中断脉冲：使用SIGEV_PULSE_PRIO_INHERIT，继承中断优先级
- 定时器脉冲：根据任务紧急程度设置固定优先级
- 状态通知：使用默认优先级即可
5.5 总结与建议
脉冲机制是QNX里最轻量的IPC方式，没有之一。它的设计哲学就是“快、准、狠”——不拖泥带水，不等待回复。
我个人建议：
- 能用脉冲就别用消息：如果只是通知事件，不需要回复，脉冲是首选
- 注意脉冲优先级：别让低优先级的脉冲阻塞了高优先级的
- 别在脉冲里传大数据：40字节是硬限制，超了就用消息或共享内存
- 中断处理用脉冲：这是QNX的标准做法，别在ISR里做复杂操作
我曾经见过一个团队，把所有IPC都写成消息模式，结果系统响应时间惨不忍睹。后来我帮他们改成脉冲+消息混合模式——关键事件用脉冲通知，数据交换用消息传递——性能直接翻倍。所以说，选对工具很重要。
下一章我们会深入讲消息传递机制，到时候你会看到脉冲和消息如何配合使用。先消化好脉冲这部分，后面就顺了。