В многопоточной среде синхронизация между задачами может осуществляться через глобальные переменные, очереди и семафоры. В случае использования глобальных переменных встает вопрос их защиты от конкурентного доступа.

В ESP-IDF для защиты глобальных переменных от конкурентного доступа в многозадачной среде (включая двухъядерные ESP32) используется несколько основных подходов. Выбор зависит от того, где и как долго происходит доступ к данным, а также от сложности операции.

[Мьютексы (Mutexes) — для задач с длительными операциями]

Мьютекс — это стандартный и самый безопасный механизм для защиты ресурсов, разделяемых между задачами.

Принцип работы: задача, которая хочет получить доступ к переменной, должна сначала "захватить" (take) мьютекс. Если мьютекс уже занят другой задачей, пытающаяся захватить его задача переводится в состояние блокировки (сна) до его освобождения.

Применение: идеально подходит для ситуаций, когда критическая секция занимает относительно много времени (например, содержит операции ввода-вывода, сложные вычисления).

Важная особенность: мьютексы в FreeRTOS поддерживают механизм наследования приоритетов, что помогает предотвратить проблему инверсии приоритетов (когда высокоприоритетная задача вынуждена ждать низкоприоритетную).

Ограничения: не могут использоваться из обработчиков прерываний (ISR).

SemaphoreHandle_t xMutex;

void task_function(void *pvParameters) {
    // ...
    if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
        // === КРИТИЧЕСКАЯ СЕКЦИЯ ===
        // Безопасное чтение и запись глобальной переменной
        global_var++;
        // ============================
        xSemaphoreGive(xMutex);
    }
}

Для вложенных вызовов используйте рекурсивные мьютексы: xSemaphoreCreateRecursiveMutex().

[Отключение прерываний и Spinlock'и — для сверхбыстрых операций]

Это самый строгий и быстрый в плане применения метод, но его использование должно быть минимальным.

Принцип работы: макросы portENTER_CRITICAL() и portEXIT_CRITICAL() отключают прерывания и, что критично для двухъядерных ESP32, захватывают внутренний спинлок, чтобы гарантировать, что никакая другая задача или ядро не войдут в эту секцию.

Применение: для защиты очень коротких операций, таких как инкремент счетчика или изменение флага. На двухъядерных ESP32 это основной способ синхронизации доступа к ресурсу между ядрами.

Предупреждение: этот метод увеличивает задержку обработки прерываний. Критическая секция должна быть максимально короткой. Если задерживать ее надолго, это может привести к срабатыванию сторожевого таймера (watchdog) и перезагрузке системы.

portMUX_TYPE my_spinlock = portMUX_INITIALIZER_UNLOCKED;

void some_function() {
    portENTER_CRITICAL(&my_spinlock);
    // === КРИТИЧЕСКАЯ СЕКЦИЯ ===
    // Очень короткая операция, например, global_counter++;
    // ============================
    portEXIT_CRITICAL(&my_spinlock);
}

// Глобальные переменные
portMUX_TYPE my_spinlock = portMUX_INITIALIZER_UNLOCKED;
int global_counter = 0;
float global_temperature = 25.0;
bool global_status = false;

// Функция чтения
int read_counter() {
    int value;
    portENTER_CRITICAL(&my_spinlock);
    value = global_counter;
    portEXIT_CRITICAL(&my_spinlock);
    return value;
}

// Функция записи
void write_counter(int new_value) {
    portENTER_CRITICAL(&my_spinlock);
    global_counter = new_value;
    portEXIT_CRITICAL(&my_spinlock);
}

// НЕПРАВИЛЬНО:
// Одна задача пишет
portENTER_CRITICAL(&my_spinlock);
global_counter = 10;

portEXIT_CRITICAL(&my_spinlock);

// Другая задача читает БЕЗ защиты - ОПАСНО!
int value = global_counter; // Гонка данных!

// ПРАВИЛЬНО:
// Все задачи должны использовать одну и ту же защиту
int value;
portENTER_CRITICAL(&my_spinlock);
value = global_counter;
portEXIT_CRITICAL(&my_spinlock);

portMUX_TYPE my_spinlock = portMUX_INITIALIZER_UNLOCKED;

int x = 0;
int y = 0;

// ПРАВИЛЬНО - защита обеих переменных в одной критической секции
void update_coordinates(int new_x, int new_y) {
    portENTER_CRITICAL(&my_spinlock);
    x = new_x;
    y = new_y;
    portEXIT_CRITICAL(&my_spinlock);
}

void read_coordinates(int* out_x, int* out_y) {
    portENTER_CRITICAL(&my_spinlock);
    *out_x = x;
    *out_y = y;
    portEXIT_CRITICAL(&my_spinlock);
}

// В ISR (Interrupt Service Routine) - ОПАСНО, если прерывание выше порога
void IRAM_ATTR my_isr() {
    portENTER_CRITICAL(&my_spinlock); // Может привести к deadlock!
    // ... код ...
    portEXIT_CRITICAL(&my_spinlock);
}

// Для ISR используйте portENTER_CRITICAL_ISR/portEXIT_CRITICAL_ISR
void IRAM_ATTR my_isr() {
    portENTER_CRITICAL_ISR(&my_spinlock);
    // ... код ...
    portEXIT_CRITICAL_ISR(&my_spinlock);
}

// Это безопасно, если используется один и тот же spinlock
portENTER_CRITICAL(&my_spinlock);
// ...
// Вложенный вход в критическую секцию:
portENTER_CRITICAL(&my_spinlock);
// ...
portEXIT_CRITICAL(&my_spinlock);
// ...
portEXIT_CRITICAL(&my_spinlock);

portMUX_TYPE lock_peripheral = portMUX_INITIALIZER_UNLOCKED;
portMUX_TYPE lock_state = portMUX_INITIALIZER_UNLOCKED;

// Переменные, связанные с периферией
int adc_value = 0;
float voltage = 0.0;

// Переменные состояния
bool is_connected = false;
uint32_t error_code = 0;

// Используем разные lock'и для независимых групп
void update_adc(int value) {
    portENTER_CRITICAL(&lock_peripheral);
    adc_value = value;
    voltage = value * 0.0033;
    portEXIT_CRITICAL(&lock_peripheral);
}

void set_error(uint32_t code) {
    portENTER_CRITICAL(&lock_state);
    error_code = code;
    is_connected = false;
    portEXIT_CRITICAL(&lock_state);
}

#include < stdatomic.h>

atomic_int counter = 0;

// Не нужна критическая секция для простых атомарных операций
int increment_counter() {
    return atomic_fetch_add(&counter, 1);
}

int read_counter() {
    return atomic_load(&counter);
}

SemaphoreHandle_t mutex = xSemaphoreCreateMutex();

void long_operation() {
    if (xSemaphoreTake(mutex, portMAX_DELAY) == pdTRUE) {
        // Длительная операция с глобальными переменными
        // Можно использовать yield/sleep внутри
        // ...
        xSemaphoreGive(mutex);
    }
}

[Атомарные операции — для простых типов данных]

Для защиты простых 32-битных (и даже 8-битных и 16-битных) переменных можно использовать C++ std::atomic (для C существует аналогичный тип atomic_int). Это современный и эффективный способ.

Принцип работы: тип данных std::atomic (и atomic_int) гарантирует, что операции над переменной (чтение, запись, инкремент) выполняются как единое, неделимое действие на аппаратном уровне.

Применение: идеально подходит для простых счетчиков и флагов, которые инкрементируются или изменяются в прерываниях или задачах.

Производительность: как правило это быстрее, чем спинлок, так как для атомарных операций используется аппаратная поддержка (команды s32c1i в архитектуре Xtensa). Класс std::atomic для типов uint8_t, uint16_t и uint32_t реализован без использования программных блокировок (is_lock_free() возвращает true).

#include < atomic>

std::atomic< int> global_counter(0);

void IRAM_ATTR isr_handler() {
    // Безопасный инкремент из прерывания
    global_counter.fetch_add(1, std::memory_order_relaxed);
}

void task_function() {
    // Безопасное чтение
    int current_value = global_counter.load(std::memory_order_relaxed);
    // Безопасное уменьшение
    global_counter.fetch_sub(10, std::memory_order_relaxed);
}

Тип atomic_int в ESP-IDF определен в стандартном заголовочном файле stdatomic.h, который входит в состав библиотеки newlib. Его точное местоположение в файловой системе SDK — components/newlib/include/stdatomic.h.

Чтобы использовать его в своем коде, достаточно добавить:

#include < stdatomic.h>

Важные нюансы при использовании. Хотя stdatomic.h и предоставляет стандартный интерфейс для атомарных операций, в ESP-IDF есть некоторые особенности, о которых стоит знать:

1. Аппаратная поддержка: для многих атомарных операций, особенно для типов размером 32 бита (например, atomic_int на ESP32), аппаратная поддержка работает корректно и обеспечивает высокую производительность.

2. Эмуляция через spinlock: для типов, которые не поддерживаются аппаратно (например, 64-битные на некоторых чипах, или пользовательские структуры), реализация в ESP-IDF может использовать критическую секцию, вызывая portENTER_CRITICAL(). Это означает, что такая операция может быть не безблокировочной (lock-free) в полном смысле, но она по-прежнему безопасна для использования в многозадачной среде.

3. Глобальный spinlock: согласно некоторым обсуждениям, все программные атомарные операции в ESP-IDF могут использовать один и тот же глобальный spinlock. Это гарантирует безопасность, но в ситуациях с очень высокой конкуренцией (когда множество задач одновременно выполняют атомарные операции) это может стать узким местом производительности.

Сводная таблица выбора метода:

Резюме:

● Для простых счетчиков и флагов в современном коде на C++ предпочтительнее использовать std::atomic.
● Для защиты больших массивов данных, структур или в случаях с длительными вычислениями выбирайте мьютекс.
● Для "быстрой и грязной" защиты пары строк кода внутри задачи или ISR, особенно в условиях многопоточности, подойдет критическая секция со спинлоком (portENTER_CRITICAL()).

[Очереди]

Можно ли заменить глобальные переменные очередями для синхронизации задач?

Краткий ответ: да, можно и часто нужно. Но это не универсальная замена "всех" глобальных переменных. Очереди (Queues) в FreeRTOS — это не просто средство передачи данных, а мощный инструмент синхронизации, который во многих сценариях делает глобальные переменные с мьютексами излишними и даже вредными.

Вот подробный разбор, когда и как очереди заменяют глобальные переменные, а когда — нет.

1. Почему очереди лучше глобальных переменных (в ряде случаев). Когда вы используете глобальную переменную + мьютекс, задача, чтобы узнать новое значение, должна постоянно опрашивать переменную (поллинг) или ждать уведомления. 

Очередь же работает по принципу "отправил и забыл" и "блокирующего ожидания":

- Отсутствие активного ожидания (Busy-Wait): если глобальная переменная пуста, задача-потребитель, использующая xQueueReceive() с portMAX_DELAY, перейдет в спящий режим (заблокируется). Она НЕ потребляет процессорное время. Как только продюсер отправит данные в очередь, планировщик мгновенно разбудит потребителя.
- Встроенная защита: очереди потокобезопасны "из коробки". Вам не нужны ни мьютексы, ни критические секции для чтения/записи очереди из разных задач и прерываний (ISR).
- Синхронизация событий: отправив сообщение, вы не просто меняете значение, вы генерируете событие. Задача-приемник точно знает, что данные обновились, и не тратит время на сравнение старого и нового значения.

Пример замены: вместо глобального флага `bool sensor_ready` + мьютекс, вы создаете очередь длиной 1. Как только датчик готов — отправляете в очередь true (или любое значение). Задача, ожидающая датчик, висит на xQueueReceive() и просыпается только в момент готовности.

2. Когда очередь НЕ заменяет глобальные переменные. Есть сценарии, где использование очереди вместо глобальной переменной — это "стрельба из пушки по воробьям" или технически невозможно:

- Доступ из разных мест без "потребления" данных. Если вам нужно, чтобы несколько задач одновременно читали текущее состояние системы (например, текущая температура), а не забирали его из очереди (удаляя), то очередь не подходит. Прочитав из очереди, вы его удаляете. Для таких случаев лучше оставить глобальную переменную (std::atomic< float> current_temp).
- Очень частая передача больших объемов данных. Очереди работают через копирование (копируют данные из буфера отправителя во внутренний буфер очереди). Если вы кладете в очередь огромную структуру данных (фрейм изображения, БД) — это будет жутко нагружать память и CPU. Здесь лучше оставить глобальную переменную (указатель) + мьютекс, либо использовать очереди для передачи указателя на эти данные.
- Сохранение состояния (State Machine). Глобальная переменная current_state машины состояний должна быть доступна по чтению в любой момент времени без изменения. Очередь для этого не годится.

3. "Неочевидная" замена: очередь как мьютекс (бинарный семафор). В ESP-IDF есть специальный прием: если ваша глобальная переменная — это просто флаг "Ресурс занят/свободен", вы можете вообще убрать переменную и мьютекс, используя очередь длиной 1 как бинарный семафор.

// Вместо:
// bool uart_busy;
// SemaphoreHandle_t uart_mutex;

// Делаем очередь (бинарный семафор)
QueueHandle_t uart_queue = xQueueCreate(1, sizeof(uint8_t));

// Инициализация: кладем один "токен" свободы
uint8_t token = 1;
xQueueSend(uart_queue, &token, 0);

// Задача А хочет занять UART
void task_A() {
    uint8_t received;
    if (xQueueReceive(uart_queue, &received, portMAX_DELAY) == pdTRUE) {
        // === МЫ ЗАХВАТИЛИ РЕСУРС ===
        // Работаем с UART...

        // Освобождаем ресурс (возвращаем токен обратно)
        xQueueSend(uart_queue, &received, 0);
    }
}

Это работает быстрее классического мьютекса в некоторых случаях, но не наследует приоритеты, поэтому используйте осторожно.

4. Альтернатива для синхронизации: очереди сообщений (Events). Если глобальные переменные используются для передачи разнородных событий (например, `system_error = 5`, `wifi_connected = true`), то вместо набора флагов удобно использовать очередь структур:

typedef struct {
    uint8_t event_type; // 1 - WIFI, 2 - BUTTON, 3 - TEMP
    int value;
} system_event_t;

QueueHandle_t event_queue = xQueueCreate(10, sizeof(system_event_t));

// Задача-обработчик
void main_handler() {
    system_event_t evt;
    while(1) {
        if(xQueueReceive(event_queue, &evt, portMAX_DELAY)) {
            switch(evt.event_type) {
                case TEMP: global_temperature = evt.value; break; // Обновили глобалку
            }
        }
    }
}

Итоговое резюме:

Вывод: очереди это лучший способ уведомить задачу об изменении данных. Однако для хранения актуального значения по умолчанию, к которому нужен одновременный доступ на чтение, глобальные переменные (защищенные атомарными операциями) остаются лучшим выбором. В связке они работают отлично: прерывание пишет в очередь -> задача-обработчик читает из очереди и обновляет защищенную глобальную переменную.

[Ссылки]

1. ESP-IDF FreeRTOS Task API.
2. ESP-IDF FreeRTOS SMP.
3. Чем отличается мьютекс от семафора?
4. 9 способов испортить код с помощью volatile.