引言

ESP32 搭载 Xtensa 双核处理器，FreeRTOS 支持对称多处理（SMP）。任务通知（Task Notification）相比信号量（Semaphore）更轻量（无内核对象、直接操作任务控制块），但多核环境下，缓存一致性（Cache Coherence）问题可能让看似正确的代码陷入死锁。本文面向有 FreeRTOS 基础的开发者，深入探讨问题根源并提供规避策略。

一、任务通知与信号量的本质差异

信号量：内核对象，通过队列实现，操作涉及临界区保护（关中断或自旋锁），开销较大。
任务通知：直接向目标任务发送 32 位值或事件位，无需额外内核对象，速度提升约 30%。
多核影响：在 SMP 下，信号量使用自旋锁保证原子性，而任务通知依赖硬件原子指令（如 S32C1I），但缓存一致性仍需软件配合。

二、缓存一致性如何引发死锁

2.1 缓存一致性协议

ESP32 使用 MESI 协议（Modified, Exclusive, Shared, Invalid）。每个核心有独立 L1 缓存，当 Core0 修改变量时，Core1 的缓存副本被标记为 Invalid，需从内存重新读取。

2.2 死锁场景

假设两个任务：

任务 A（Core0）等待任务 B（Core1）的通知，同时持有锁 L。
任务 B 等待锁 L，同时向任务 A 发送通知。

若任务通知的发送操作未正确处理缓存一致性，可能导致：

Core0 发送通知，但通知值仍留在 Core0 的缓存中，未同步到内存。
Core1 检查任务状态时，读到旧值（Invalid 未刷新），认为通知未到达，继续等待锁。
Core0 等待锁释放，形成死锁。

根本原因：任务通知的 xTaskNotifyGive 内部使用原子操作，但原子操作仅保证单核原子性，不保证跨核可见性（除非使用完整内存屏障）。

三、规避策略

3.1 使用原子操作与内存屏障

FreeRTOS 提供 portENTER_CRITICAL 和 portEXIT_CRITICAL，在 SMP 下会使用自旋锁，但开销较大。更优方案是使用 atomic 操作（如 atomic_fetch_add）并配合 __sync_synchronize() 内存屏障。

3.2 避免共享变量跨核访问

将任务通知的目标任务固定在同一核心（通过 xTaskCreatePinnedToCore），减少跨核缓存同步。

3.3 使用队列替代（但保持轻量）

若必须跨核，可考虑使用 xQueueSendFromISR 等，但队列本身有锁，性能略降。

3.4 显式内存屏障

在发送通知后，调用 portMEMORY_BARRIER()（ESP-IDF 提供）确保写入对其他核心可见。

四、配置步骤与代码示例

4.1 项目配置

在 ESP-IDF 中启用 SMP：

menuconfig -> FreeRTOS -> SMP -> 支持多核

4.2 错误示例（可能死锁）

// 任务A（Core0）
void taskA(void *arg) {
    while (1) {
        xSemaphoreTake(lock, portMAX_DELAY);
        // 等待任务B的通知
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        // 处理数据
        xSemaphoreGive(lock);
    }
}

// 任务B（Core1）
void taskB(void *arg) {
    while (1) {
        xSemaphoreTake(lock, portMAX_DELAY);
        // 发送通知给任务A
        xTaskNotifyGive(taskAHandle);
        xSemaphoreGive(lock);
    }
}

此代码中，任务B持有锁时发送通知，但通知的写入可能未及时同步，任务A在等待通知时持有锁，导致死锁。

4.3 正确示例（使用内存屏障和原子操作）

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_attr.h"
#include <atomic>

static std::atomic<bool> data_ready{false};
static SemaphoreHandle_t lock;

// 任务A（Core0）
void taskA(void *arg) {
    while (1) {
        xSemaphoreTake(lock, portMAX_DELAY);
        // 等待数据就绪标志（原子操作）
        while (!data_ready.load(std::memory_order_acquire)) {
            // 短暂等待，避免忙等
            vTaskDelay(pdMS_TO_TICKS(1));
        }
        // 处理数据
        data_ready.store(false, std::memory_order_release);
        xSemaphoreGive(lock);
    }
}

// 任务B（Core1）
void taskB(void *arg) {
    while (1) {
        xSemaphoreTake(lock, portMAX_DELAY);
        // 准备数据
        // 使用原子存储并释放语义
        data_ready.store(true, std::memory_order_release);
        // 显式内存屏障，确保跨核可见
        portMEMORY_BARRIER();
        // 可选：发送通知作为唤醒信号（但数据同步由原子变量保证）
        xTaskNotifyGive(taskAHandle);
        xSemaphoreGive(lock);
    }
}

关键点：

使用 std::atomic 保证原子性，memory_order_release/acquire 提供跨核同步。
portMEMORY_BARRIER() 强制刷新缓存，确保写入对其他核心可见。
任务A在等待时使用 vTaskDelay 让出 CPU，避免忙等。

4.4 更优方案：固定核心运行

若任务间通信频繁，可将两个任务固定在同一核心，避免跨核缓存问题：

xTaskCreatePinnedToCore(taskA, "A", 2048, NULL, 1, &taskAHandle, 0); // Core0
xTaskCreatePinnedToCore(taskB, "B", 2048, NULL, 1, &taskBHandle, 0); // Core0

此时任务通知完全在单核内，无缓存一致性问题，性能最佳。

五、注意事项

内存屏障开销：portMEMORY_BARRIER 会刷新流水线，高频调用会降低性能，建议仅在关键同步点使用。
原子操作与 FreeRTOS 兼容性：确保使用 C++11 原子或 GCC 内建原子，避免与 FreeRTOS 内部锁冲突。
调试技巧：使用 xTaskGetCoreID() 检查任务运行核心，利用 vTaskList 查看任务状态。
死锁检测：开启 FreeRTOS 的 configUSE_TRACE_FACILITY 和 configUSE_STATS_FORMATTING_FUNCTIONS，通过 vTaskGetRunTimeStats 分析。
避免忙等：使用 ulTaskNotifyTake 配合超时，或使用事件组。

六、总结

ESP32 多核环境下，任务通知虽高效，但缓存一致性不容忽视。通过原子操作、内存屏障、固定核心运行等策略，可有效避免死锁。实际项目中，建议优先考虑固定核心分配，其次使用原子变量同步数据，任务通知仅作唤醒信号。理解底层硬件一致性协议，是写出健壮嵌入式代码的关键。

ESP32 多核 FreeRTOS 任务通知替代信号量：缓存一致性死锁的规避策略

引言