以太网温湿度传感器多协议并发访问冲突：当 Modbus TCP 轮询遇上 SNMP Trap 时的锁机制探讨

以太网温湿度传感器多协议并发访问冲突：当 Modbus TCP 轮询遇上 SNMP Trap 时的锁机制探讨

在智慧档案馆、机房动环等场景中，一个以太网温湿度传感器往往同时扮演着两个角色：

1. 被轮询者：SCADA/三维可视化系统通过 Modbus TCP​ 周期性读取寄存器（如 40001 温度、40003 湿度）；
2. 主动通告者：当温湿度越限或设备状态变化时，通过 SNMP Trap​ 主动向网管系统（NMS）推送告警。

这带来了嵌入式软件开发中的一个经典问题：当 Modbus TCP 正在读取传感器数据缓冲区时，SNMP Trap 任务是否允许打断并改写同一块数据？

如果处理不当，就会出现“脏读”（Dirty Read）——SCADA 读到一个正在被修改的半更新数据，或者 SNMP Trap 发出一个已经被覆盖的旧值。本文深入剖析这一并发冲突，并探讨嵌入式环境下的锁机制设计。

一、冲突场景还原：数据“撕裂”是如何发生的

假设传感器内部有一个全局结构体 env_data，用于存储最新的环境参数：

typedef struct {
    int32_t temperature; // 温度，放大10倍存储
    int32_t humidity;    // 湿度，放大10倍存储
    int32_t dew_point;   // 露点
} env_data_t;

1. 场景描述

• Task A (Modbus TCP Server)：正在执行 read_holding_registers()。它需要读取 temperature 和 humidity，并将其填入 TCP 响应报文。
• Task B (SNMP Agent/Trap Sender)：检测到湿度越限，准备发送 Trap。它需要读取 temperature 和 humidity，填入 Trap PDU。
• Task C (Sensor Sampling)：ADC 采样完成，计算出新的温湿度，准备更新 env_data。

2. “撕裂读”（Torn Read）问题

在 32 位 MCU 上，读取 64 位结构体（或连续的两个 32 位变量）通常不是原子操作。

1. Task A 读取 temperature（新值：256，代表 25.6℃）。
2. 此时 Task C 抢占了 CPU，更新了 env_data：temperature 变为 258，humidity 变为 550。
3. Task A 恢复运行，继续读取 humidity（新值：550，代表 55.0% RH）。
4. 结果：Task A 将 256（新温）和 550（新湿）组合发送给 SCADA。

看起来没问题？错！​ 如果 Task C 更新到一半被打断呢？

1. Task C 更新 temperature = 258。
2. 此时 Task A 抢占了 CPU。
3. Task A 读取 temperature（新值：258）。
4. Task A 读取 humidity（旧值：520，代表 52.0% RH，因为 Task C 还没来得及更新它）。
5. 结果：SCADA 收到 25.8℃ / 52.0% RH。这是一个逻辑上不存在的瞬间状态（温湿度不匹配），导致曲线出现无法解释的“毛刺”或误告警。

二、嵌入式锁机制选型：从互斥量到无锁编程

针对上述问题，嵌入式系统（RTOS 环境，如 FreeRTOS、RT-Thread）通常采用以下几种同步机制。

1. 互斥量（Mutex）：最通用的方案

原理：创建一个全局互斥量（Mutex）。Task A 和 Task B 在读取 env_data 前必须先 take Mutex，读完 give Mutex。Task C 在更新前也必须 take Mutex。

// 伪代码
void modbus_read_callback() {
    xSemaphoreTake(xEnvDataMutex, portMAX_DELAY);
    // 安全地读取 env_data
    response.temp = env_data.temperature;
    response.humi = env_data.humidity;
    xSemaphoreGive(xEnvDataMutex);
}

void sensor_update_task() {
    xSemaphoreTake(xEnvDataMutex, portMAX_DELAY);
    // 安全地更新 env_data
    env_data.temperature = new_temp;
    env_data.humidity = new_humi;
    xSemaphoreGive(xEnvDataMutex);
}

优点：实现简单，逻辑清晰，保证数据一致性。

缺点：

• 优先级反转：如果低优先级任务持有锁，高优先级任务（如网络中断）可能阻塞。需使用带优先级继承协议的 Mutex。
• 中断上下文不可用：Mutex 不能在中断服务程序（ISR）中使用。如果 SNMP Trap 是在网络栈的回调中触发（接近 ISR），则不能用 Mutex。

2. 临界区（Critical Section）：短平快

原理：在读取/更新共享数据时，关闭全局中断或调度器。

void modbus_read_callback() {
    taskENTER_CRITICAL();
    // 原子操作
    local_temp = env_data.temperature;
    local_humi = env_data.humidity;
    taskEXIT_CRITICAL();
    // 后续处理
}

优点：绝对原子性，无优先级反转问题。

缺点：严重增加中断延迟。如果 env_data 很大或处理复杂，关中断时间过长会影响系统实时性（如 POE 供电的脉冲检测）。仅适用于极短的操作。

3. 双缓冲区（Double Buffer）：无锁编程的优雅解

原理：设立两个缓冲区 Buffer_A 和 Buffer_B。

• Task C（采样）始终只写入后台缓冲区（如 Buffer_B）。
• Task A/B（Modbus/SNMP）始终只读取前台缓冲区（如 Buffer_A）。
• 当新数据准备好后，交换指针（或标志位）。

env_data_t buffer[2];
volatile uint8_t read_idx = 0;
volatile uint8_t write_idx = 1;

void sensor_update_task() {
    // 写入后台
    buffer[write_idx].temperature = new_temp;
    buffer[write_idx].humidity = new_humi;
    // 交换角色（原子操作）
    int temp = read_idx;
    read_idx = write_idx;
    write_idx = temp;
}

void modbus_read_callback() {
    // 读取前台（无需锁，因为只读，且交换指针是原子操作）
    local_temp = buffer[read_idx].temperature;
    local_humi = buffer[read_idx].humidity;
}

优点：读写完全分离，无锁，无阻塞，性能极高。

缺点：稍微增加内存占用；数据有一帧的延迟（读到的总是上一帧的数据，但在温湿度监测中完全可接受）。

4. 序列号/版本号（Seq Num）：乐观并发控制

原理：在结构体中增加一个 seq 字段。

1. 读取 seq (V1)。
2. 读取数据。
3. 再次读取 seq (V2)。
4. 如果 V1 == V2，说明读取过程中未被打断，数据有效；否则重试。

优点：无锁，实现简单。

缺点：在竞争激烈时可能导致多次重试；对 32 位对齐有要求。

三、针对 Modbus TCP + SNMP Trap 的推荐架构

结合温湿度传感器的特性（数据量小、变化慢、允许微秒级延迟），推荐采用 “双缓冲区 + 原子指针交换”​ 的方案。

1. 架构设计

• 数据区：定义两个 env_data_t 实例。
• 指针：定义一个 volatile env_data_t* current_ptr，指向当前有效的数据块（供 Modbus/SNMP 读取）。
• 采样任务：
  1. 向 next_ptr（非当前指针）写入新数据。
  2. 写入完成后，通过原子操作将 current_ptr 指向 next_ptr。
• 协议栈回调（Modbus/SNMP）：
  1. 直接读取 current_ptr 指向的数据。
  2. 由于指针赋值在 32 位 MCU 上是原子操作，不会出现读到一半指针的情况。

2. 为什么这个方案最适合？

• Modbus TCP：通常运行在 TCP 服务器任务中，优先级中等。它只需要读指针，无需等待锁。
• SNMP Trap：通常由定时器或中断触发，需要快速响应。双缓冲避免了 Trap 任务因等待 Mutex 而阻塞，确保告警及时发出。
• 传感器采样：可能由定时器触发。写操作在后台完成，不影响前台数据的一致性。

3. SNMP Trap 的特殊性处理

SNMP Trap 通常是基于 UDP 的，且由 Agent 进程触发。在嵌入式系统中，Trap 的生成往往涉及：

1. 事件检测（在采样任务中）。
2. PDU 构建（在 SNMP Agent 任务中）。
3. UDP 发送（在网络栈中）。

关键点：Trap 中携带的 sysUpTime 和变量绑定值（OID 对应的值）必须是一致的瞬间状态。

• 使用双缓冲后，Agent 任务在构建 PDU 时，锁定当前指针，拷贝一份数据到局部变量，然后释放指针。这确保了 Trap 报文内部的数据是匹配的。

四、工程落地中的“坑”与对策

坑 1：Modbus TCP 寄存器映射与内存布局不一致

• 现象：读取到的温湿度数值错位。
• 原因：Modbus 寄存器是 16 位字，而 C 结构体是 32 位。直接映射结构体指针到寄存器区会导致字节序和字对齐问题。
• 对策：使用显式的寄存器拷贝函数，而不是内存映射。在拷贝函数内部使用双缓冲或临界区保护。

坑 2：SNMP MIB 中的 Counter/Guage 类型更新不同步

• 现象：Trap 中的湿度值与 Get 请求得到的值不一致。
• 原因：Trap 发送时读取了一个缓冲区，而 Get 请求响应时读取了另一个缓冲区（在指针交换的瞬间）。
• 对策：在 SNMP Agent 内部，对于所有 Get/GetNext/Trap 请求，统一通过一个只读接口获取数据，该接口返回当前指针指向的数据副本。

坑 3：网络栈回调中的阻塞调用

• 现象：系统死锁或网络超时。
• 原因：在 lwIP 等网络栈的回调函数中（如 recv 回调），调用了 xSemaphoreTake（Mutex）。网络栈回调可能运行在中断上下文或特殊任务中，不允许阻塞。
• 对策：绝对不在网络回调中使用 Mutex。使用双缓冲方案，网络回调只需读取指针，极其快速，不会阻塞。

五、总结：并发控制的设计哲学

在以太网温湿度传感器这种资源受限、多协议并发的嵌入式设备中，设计并发控制机制时，请遵循以下原则：

1. 读写分离：能双缓冲，不共享。这是解决 Modbus TCP 与 SNMP Trap 冲突的最优解。
2. 缩短临界区：如果必须用锁（Mutex），临界区内只做拷贝，不做计算或 I/O。
3. 中断安全：网络回调和硬件中断中，严禁使用可能导致阻塞的同步原语。
4. 数据一致性优先：在温湿度监测中，数据的逻辑一致性（温湿匹配）远比实时性（微秒级延迟）重要。

最终推荐方案：

采用双缓冲区（Double Buffer）+ 原子指针交换。 Modbus TCP 和 SNMP Trap 始终读取当前活跃缓冲区，传感器采样始终写入后台缓冲区。指针交换瞬间完成，确保两个协议看到的数据永远是某一时刻的完整快照。

这种设计不仅解决了并发冲突，还最大程度地降低了协议栈之间的耦合度，提升了系统的稳定性和实时性。