引言

在 ESP32 这种双核 MCU 上运行 FreeRTOS，多任务并发访问共享变量是家常便饭。但你是否遇到过：明明用 portENTER_CRITICAL() 保护了变量，程序却偶尔出现诡异行为？或者中断延迟大到无法接受？问题可能就出在临界区本身。本文将带你用原子操作（Atomic Operation）替代临界区，从根源解决变量撕裂，同时提升系统实时性。

变量撕裂的根源

什么是变量撕裂

变量撕裂（Torn Read/Write）指一个任务在读取或写入变量时，另一个任务或中断插入了操作，导致数据不完整或逻辑错误。例如，一个 32 位变量在 32 位总线上本可一次读写，但若编译器优化或硬件不支持单指令访问，就可能被拆成多条指令，中间被打断。

ESP32 双核的特殊性

ESP32 采用 Xtensa LX6 双核，两个核心共享内存。FreeRTOS 调度器允许任务在不同核心上并行运行，这意味着即使关中断（单核临界区）也无法阻止另一核的访问。传统 portENTER_CRITICAL() 在 ESP-IDF 中会通过自旋锁（Spinlock）实现多核互斥，但代价是：

阻塞其他核心的中断和任务，影响实时性
若临界区过长，可能引发优先级反转
嵌套使用易出错

原子操作：硬件级的解决方案

原子操作由硬件保证，在单条指令内完成读-改-写，不可被中断或跨核干扰。ESP32 的 Xtensa 架构支持多种原子指令，ESP-IDF 封装为便捷的 API。

核心 API

ESP-IDF 提供 portMUX_TYPE 和一系列原子操作函数，最常用的是：

atomic_xxx() 系列（C11 标准）
esp_atomic_xxx() 系列（ESP 专用）

本文以 C11 标准原子操作为主，因为其可移植性好，且编译器能生成最优指令。

实战：用原子操作替代临界区

场景描述

假设我们有一个计数器 counter，由任务 A 递增，任务 B 读取并清零。传统做法用临界区保护，现在我们改用原子操作。

步骤 1：定义原子变量

#include <stdatomic.h>

atomic_uint32_t counter = 0;  // 原子无符号 32 位变量

步骤 2：原子递增

任务 A 中，使用 atomic_fetch_add 原子递增：

void task_A(void *arg) {
    while (1) {
        atomic_fetch_add(&counter, 1);  // 原子加 1
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

步骤 3：原子读取并清零

任务 B 中，使用 atomic_exchange 原子交换，读取旧值并置零：

void task_B(void *arg) {
    while (1) {
        uint32_t val = atomic_exchange(&counter, 0);  // 原子读-清零
        printf("Counter = %u\n", val);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

完整代码示例

#include <stdio.h>
#include <stdatomic.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

atomic_uint32_t counter = 0;

void task_A(void *arg) {
    while (1) {
        atomic_fetch_add(&counter, 1);
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void task_B(void *arg) {
    while (1) {
        uint32_t val = atomic_exchange(&counter, 0);
        printf("Counter = %u\n", val);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void app_main(void) {
    xTaskCreatePinnedToCore(task_A, "task_A", 2048, NULL, 1, NULL, 0);
    xTaskCreatePinnedToCore(task_B, "task_B", 2048, NULL, 1, NULL, 1);
}

原理深入

原子操作的硬件实现

ESP32 的 Xtensa 提供 S32C1I（比较并交换）等指令，原子操作函数会编译为这些指令，确保在多核环境下的一致性。例如，atomic_fetch_add 可能使用循环的 S32C1I 实现，但通常编译器会优化为更高效的指令。

内存序（Memory Order）

C11 原子操作支持内存序参数，默认是 memory_order_seq_cst（顺序一致），最安全但性能稍低。在嵌入式场景，若只需保证原子性，可用 memory_order_relaxed 提升性能。例如：

atomic_fetch_add_explicit(&counter, 1, memory_order_relaxed);

但注意：若变量还用于同步其他数据，则需更严格的内存序。

注意事项

原子操作仅适用于简单类型：如整型、指针，不适用于结构体或数组。
对齐要求：原子变量需对齐到其大小，ESP-IDF 通常自动处理，但自定义结构体时需注意。
性能权衡：原子操作比普通读写慢，但比临界区快得多，尤其在多核场景。
内存序选择：默认顺序一致最安全，但若性能敏感，可评估 relaxed 是否可行。
不要混合使用：同一变量不要既用原子操作又用临界区，否则可能失效。
中断上下文：原子操作可在中断中使用，但需确保中断优先级不高于原子操作内部使用的临界区（若有）。

总结

通过 ESP32 双核环境下的实战，我们验证了原子操作能有效替代临界区，解决共享变量撕裂问题，同时避免阻塞中断和优先级反转。合理使用原子操作，能让你的嵌入式代码更高效、更可靠。记住：原子操作不是万能的，但它是并发编程的利器。

ESP32 双核原子操作实战：告别临界区，根治 FreeRTOS 共享变量撕裂

引言