Решение проблемы состязания заключается в принудительном атомарном доступе с помощью того, что я называю "атомарными средствами защиты доступа". В многопоточных системах это означает использование блокировок, мьютексов и семафоров. В однопоточных системах, таких как эта, это означает запретить любое прерывание, которое может помешать и вызвать состояние гонки (вы можете думать о прерываниях, взаимодействующих с основным циклом, как о параллельном взаимодействии одного потока с другой поток, так что это как если бы у вас была многопоточная система, просто имея однопоточную систему + прерывания). Для микроконтроллеров AVR отключение прерываний в качестве защиты атомарного доступа обычно выполняется путем отключения глобальных (или всех) прерываний. НО, отключение прерываний вносит джиттер из-за задержки обработки ISR, поэтому это следует делать на как можно более короткий период времени! Это означает, что вы должны просто отключить прерывания, сделать копии volatile-переменные и повторно разрешать прерывания. Однако это важный момент: иногда, в случае использования 1-байтовой volatile-переменной, используется копия вашей переменной, которая может НЕ может быть изменено ISR в любой момент, а также само по себе действует как форма «атомарной защиты доступа»; и решает проблему сам по себе. Ниже я опубликую пример этого.

Но: ОПАСНОСТЬ ОПАСНОСТЬ! Это "лучшая практика" чтобы всегда создавать резервную копию состояния прерывания, отключать прерывания, а затем восстанавливать состояние прерывания, а не просто отключать прерывания, а затем снова включать их все время. Почему? Потому что что, если вы пишете функцию, которая иногда вызывается из самого ISR? Если вы разрешаете прерывания внутри ISR, вы просто разрешаете вложенные прерывания, что приводит к дополнительные условия гонки. Если вы точно знаете, что делаете, и вам нужны вложенные прерывания, это нормально! Но, скорее всего, кто-то просто совершает здесь ошибку и случайно включает вложенные прерывания, даже не осознавая этого, что приводит к действительно трудно отслеживаемому повреждению данных из-за вложенных прерываний. Критически важные для безопасности системы могут дать сбой и причинить вред людям, поэтому мы не можем допустить неуправляемых условий гонки.

Итак, сделайте это следующим образом:

1. Принудительная атомарность в loop() путем резервного копирования состояния прерывания.
2. Создайте копии изменчивых переменных.
3. Затем восстановите глобальное состояние прерывания.
4. Используйте только копию переменной в остальной части кода. Это (использование копии) также является формой "атомарной защиты доступа". все само по себе для более поздних блоков кода, использующих переменную, потому что использование копии вместо изменчивой переменной означает, что переменная НЕ может быть изменена в любой момент с помощью ISR. Это также обеспечивает атомарность!

Создание копии volatile-переменной и ничего больше при отключенных прерываниях минимизирует время, в течение которого прерывания отключены, делая ваш код как можно лучше! Теперь это должно выглядеть так:

1 из 3: ЛУЧШИЙ СПОСОБ!:

volatile int pos  = 0; // предположим, что эта переменная по-прежнему `int`, то есть 2 байта

void loop() {
    uint8_t SREG_bak = SREG; // резервное копирование глобального состояния прерывания
    noInterrupts(); // отключаем прерывания
    // делаем копии ваших volatile-переменных здесь
    int pos_copy = pos;
    // восстановить состояние прерывания, снова включив их, если они были включены до этого,
    // или оставить их ВЫКЛЮЧЕННЫМИ, если они были ВЫКЛЮЧЕНЫ ранее.
    SREG = SREG_bak; 

    // Теперь делайте с копией что хотите, используя ТОЛЬКО pos_copy,
    // чтобы избежать состояния гонки! (то есть: использование этой копии здесь обеспечивает
    // весь этот блок теперь должен быть естественно атомарным и сам по себе
    // является формой "атомарных средств защиты доступа", как объяснялось выше.)
    if (oldpos != pos_copy) {
        oldpos = pos_copy;
        Serial.println(pos_copy);
    }
    delay(100);
}

Решено!

Тем не менее, для полноты картины давайте рассмотрим еще 2 примера.

Здесь мы делаем весь блок операторов if атомарным. На первый взгляд это выглядит правильно, но есть две проблемы: 1) [настоящая ошибка] Serial.println будет блокироваться навсегда, если исходящий последовательный буфер заполнен, так как он использует прерывания для его очистки, и если прерывания отключены, это когда-либо произойдет, и 2) [нежелательный эффект, приводящий к проблемам с производительностью, но не ошибка] прерывания отключены в течение более длительного периода времени, чем необходимо. Вышеприведенный код был лучшим: он удерживал прерывания за минимально возможное время, просто создавая копии volatile-переменных, и гарантировал, что весь этот блок операторов if был атомарным, просто используя его копию, которая автоматически действует как «атомарная защита доступа»; сам по себе и обеспечивает атомарность в блоке операторов if.

2 из 3: у этого все еще есть 2 проблемы: одна ошибка, а другая проблема производительности, но не ошибка:

volatile int pos  = 0; // предположим, что эта переменная по-прежнему `int`, то есть 2 байта

void loop() {
    uint8_t SREG_bak = SREG; // резервное копирование глобального состояния прерывания
    noInterrupts(); // отключаем прерывания

    if (oldpos != pos) {
        oldpos = pos;
        Serial.println(pos);
    }

    // восстановить состояние прерывания, снова включив их, если они были включены до этого,
    // или оставить их ВЫКЛЮЧЕННЫМИ, если они были ВЫКЛЮЧЕНЫ ранее.
    SREG = SREG_bak; 

    delay(100);
}

И, наконец, что, если переменная volatile была бы 1-байтовой? Ну, тогда вы могли бы упростить до этого, так как чтение 1-байтовой переменной, естественно, является атомарной операцией!

3 из 3: это тоже работает (без ошибок и без проблем с производительностью), но ТОЛЬКО если ваша изменчивая переменная здесь 1-байтовая!:

// эта переменная теперь является 1-байтовой переменной, которая имеет естественное атомарное чтение и
// операции записи! (но не увеличение или уменьшение)
volatile int8_t pos  = 0; 

void loop() {
    // Сделайте копии ваших volatile-переменных здесь.
    // Будучи 1-байтовой переменной в 8-битной (1-байтовой) архитектуре ЦП, эта операция
    // уже является атомарным по своей природе, поэтому нет необходимости в "защите прерываний атомарного доступа".
    int8_t pos_copy = pos; 

    // Теперь делайте с копией что хотите, используя ТОЛЬКО pos_copy,
    // чтобы избежать состояния гонки! (то есть: использование этой копии здесь обеспечивает
    // весь этот блок теперь должен быть естественно атомарным и сам по себе
    // является формой "атомарных средств защиты доступа", как объяснялось выше.)
    if (oldpos != pos_copy) {
        oldpos = pos_copy;
        Serial.println(pos_copy);
    }
    delay(100);
}

О 3 других способах создания атомарных средств защиты доступа в 8-битных Arduino на основе AVR см. мой ответ от 2016 года здесь: https://stackoverflow.com/questions/36381932/c-decrementing -элемент-однобайтового-изменчивого-массива-не-атомарный-почему/39693278#39693278.

Последний комментарий: Пол Стоффреген — один из самых опытных специалистов по Arduino в наши дни. Я уверен, что он ошибается, но я по умолчанию доверяю всему, что он пишет. Он превосходнейший разработчик программного обеспечения и инженер: один из лучших во всем мире. Ищите ошибки в том, что он пишет, и дайте ему знать, если вы их найдете, но у вас здесь неустраненные условия гонки, так что я бы сначала посмотрел на это.

Ссылки:

1. Моя собственная проблема состояния гонки: https://stackoverflow.com/questions/36381932/c-decrementing-an-element-of-a-single-byte-volatile-array-is-not-atomic-why
2. Мое собственное решение условия гонки, демонстрирующее 3 (или 4, в зависимости от того, как вы на это смотрите) способа принудительного применения «атомарных средств защиты доступа» на 8-разрядных платах Arduino на базе AVR: https: //stackoverflow.com/questions/36381932/c-decrementing-an-element-of-a-single-byte-volatile-array-is-not-atomic-why/39693278#39693278