Следует ли по-прежнему использовать volatile для обмена данными с ISR в современном C++?

Я думаю, что в этом случае и volatile, и atomic, скорее всего, будут работать на практике на 32-битной ARM. По крайней мере, в более старой версии инструментов STM32 я видел, что на самом деле атомарность C была реализована с использованием volatile для небольших типов.

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

Однако сгенерированный код должен отличаться для типов, которые нельзя загрузить в одной инструкции. Если вы используете volatile int64_t, компилятор с радостью загрузит его двумя отдельными инструкциями. Если ISR выполняется между загрузкой двух половин переменной, вы загрузите половину старого значения и половину нового значения.

К сожалению, использование atomic<int64_t> также может привести к сбою с подпрограммами обслуживания прерываний, если реализация не является свободной от блокировок. Для Cortex-M 64-битные доступы не обязательно не блокируются, поэтому на атомарность не следует полагаться без проверки реализации. В зависимости от реализации система может заблокироваться, если механизм блокировки не является реентерабельным и прерывание происходит, пока блокировка удерживается. Начиная с C++17, это можно запросить, проверив atomic<T>::is_always_lock_free. Конкретный ответ для конкретной атомарной переменной (это может зависеть от выравнивания) можно получить, проверив flagA.is_lock_free() начиная с C++11.

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

Таким образом, правильный способ - использовать std::atomic, пока доступ не блокируется. Если вас беспокоит производительность, может оказаться целесообразным выбрать соответствующий порядок памяти и придерживаться значений, которые можно загрузить в одной инструкции.

Не использовать ни один из них было бы неправильно, компилятор проверит флаг только один раз.

Все эти функции ждут флага, но они переводятся по-разному:

#include <atomic>
#include <cstdint>

using FlagT = std::int32_t;

volatile FlagT flag = 0;
void waitV()
{
    while (!flag) {}
}

std::atomic<FlagT> flagA;
void waitA()
{
    while(!flagA) {}    
}

void waitRelaxed()
{
    while(!flagA.load(std::memory_order_relaxed)) {}    
}

FlagT wrongFlag;
void waitWrong()
{
    while(!wrongFlag) {}
}

Используя volatile, вы получаете цикл, который пересматривает флаг так, как вы хотели:

waitV():
        ldr     r2, .L5
.L2:
        ldr     r3, [r2]
        cmp     r3, #0
        beq     .L2
        bx      lr
.L5:
        .word   .LANCHOR0

Atomic с последовательным последовательным доступом по умолчанию создает синхронизированный доступ:

waitA():
        push    {r4, lr}
.L8:
        bl      __sync_synchronize
        ldr     r3, .L11
        ldr     r4, [r3, #4]
        bl      __sync_synchronize
        cmp     r4, #0
        beq     .L8
        pop     {r4}
        pop     {r0}
        bx      r0
.L11:
        .word   .LANCHOR0

Если вас не волнует порядок памяти, вы получаете рабочий цикл, как и в случае с volatile:

waitRelaxed():
        ldr     r2, .L17
.L14:
        ldr     r3, [r2, #4]
        cmp     r3, #0
        beq     .L14
        bx      lr
.L17:
        .word   .LANCHOR0

Использование ни volatile, ни atomic не укусит вас с включенной оптимизацией, так как флаг проверяется только один раз:

waitWrong():
        ldr     r3, .L24
        ldr     r3, [r3, #8]
        cmp     r3, #0
        bne     .L23
.L22:                        // infinite loop!
        b       .L22
.L23:
        bx      lr
.L24:
        .word   .LANCHOR0
flag:
flagA:
wrongFlag:

Из протестированных мной коммерческих компиляторов, не основанных на gcc или clang, все они обрабатывают чтение или запись через указатель volatile или lvalue как способные получить доступ к любому другому объекту, независимо от того, кажется ли это возможным для указатель или lvalue для попадания в рассматриваемый объект. Некоторые, такие как MSVC, официально задокументировали тот факт, что изменчивые записи имеют семантику освобождения, а изменчивые чтения имеют семантику приобретения, в то время как другим потребуется пара чтения/записи для достижения семантики получения.

Такая семантика позволяет использовать объекты volatile для создания мьютекса, который может защищать обычные объекты в системах со строгой моделью памяти (включая одноядерные системы с прерываниями) или в компиляторах, применяющих барьеры захвата/освобождения на аппаратном уровне упорядочения памяти. а не просто уровень упорядочения компилятора.

Однако ни clang, ни gcc не предлагают никакой другой опции, кроме -O0, которая предлагала бы такую ​​семантику, поскольку они препятствовали бы оптимизации, которая в противном случае могла бы преобразовать код, выполняющий кажущиеся избыточными загрузки и сохранения [которые на самом деле необходимы для правильной работы] в более эффективный код [который не работает]. Чтобы сделать код пригодным для использования с ними, я бы рекомендовал определить макрос «засорения памяти» (который для clang или gcc будет asm volatile ("" ::: "memory");) и вызывать его между действием, которое должно предшествовать изменчивой записи, и самой записью, или между изменчивой записью. read и первое действие, которое должно следовать за ним. Если кто-то сделает это, это позволит легко адаптировать код к реализациям, которые не поддерживают и не требуют таких барьеров, просто определяя макрос как пустое расширение.

Обратите внимание, что в то время как некоторые компиляторы интерпретируют все директивы asm как засорение памяти, и нет никакой другой цели для пустой директивы asm, gcc просто игнорирует пустые директивы asm, а не интерпретирует их таким образом.

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

short buffer[10];
volatile short volatile *tx_ptr;
volatile int tx_count;
void test(void)
{
    buffer[0] = 1;
    tx_ptr = buffer;
    tx_count = 1;
    while(tx_count)
        ;
    buffer[0] = 2;
    tx_ptr = buffer;
    tx_count = 1;
    while(tx_count)
        ;
}

GCC решит оптимизировать назначение buffer[0]=1;, потому что Стандарт не требует, чтобы он признавал, что сохранение адреса буфера в volatile может иметь побочные эффекты, которые будут взаимодействовать с сохраненным там значением.

[править: дальнейшие эксперименты показывают, что icc переупорядочивает доступ к volatile объектам, но поскольку он переупорядочивает их даже относительно друг друга, я не уверен, что с этим делать, так как это может показаться неправильным любой воображаемой интерпретацией Стандарта].

Чтобы понять проблему, вы должны сначала понять, зачем вообще нужен volatile.

Здесь есть три совершенно разных вопроса:

1. Неправильная оптимизация, потому что компилятор не понимает, что на самом деле вызываются аппаратные обратные вызовы, такие как ISR.

   Решение: volatile или осведомленность компилятора.

2. Ошибки повторного входа и состояния гонки, вызванные доступом к переменной в нескольких инструкциях и прерыванием в середине этого ISR, использующим ту же переменную.

   Решение: защищенный или атомарный доступ с мьютексом, _Atomic, отключенными прерываниями и т. д.

3. Ошибки параллелизма или предварительной выборки кэша, вызванные переупорядочением инструкций, многоядерным выполнением, прогнозированием ветвлений.

   Решение: барьеры памяти или выделение/выполнение в областях памяти, которые не кэшируются. volatile доступ может или не может действовать как барьер памяти в некоторых системах.

Как только кто-то поднимает такой вопрос о SO, вы всегда получаете множество программистов для ПК, болтающих о 2 и 3, ничего не зная или не понимая о 1. Это потому, что они никогда в своей жизни не писали ISR и компиляторы для ПК с несколькими -threading, как правило, знает, что будут выполняться обратные вызовы потоков, поэтому в программах для ПК это обычно не проблема.

Что вам нужно сделать, чтобы решить 1) в вашем случае, это посмотреть, действительно ли компилятор генерирует код для чтения while (!flag) с включенной оптимизацией или без нее. Разобрать и проверить.

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

К сожалению, большинство компиляторов используют только ключевые слова interrupt etc для создания правильных соглашений о вызовах и инструкций возврата. Недавно я столкнулся с недостающей ошибкой volatile всего несколько недель назад, помогая кому-то на сайте SE, и они использовали современную цепочку инструментов ARM. Поэтому я не верю, что компиляторы справятся с этим в 2020 году, если только они явно не задокументируют это. Если вы сомневаетесь, используйте volatile.

Что касается 2) и повторного входа, современные компиляторы в настоящее время поддерживают _Atomic, что очень упрощает задачу. Используйте его, если он доступен и надежен в вашем компиляторе. В противном случае для большинства систем с «голым железом» вы можете использовать тот факт, что прерывания не прерываются, и использовать обычное логическое значение в качестве облегченного мьютекса (example), если нет переупорядочения инструкций (маловероятный случай для большинства микроконтроллеров).

Но обратите внимание, что 2) – это отдельная проблема, не связанная с volatile. volatile не решает потокобезопасный доступ. Поточно-ориентированный доступ не устраняет неправильные оптимизации. Так что не смешивайте эти две несвязанные концепции в одном беспорядке, как это часто бывает на SO.

Краткий ответ: всегда используйте std::atomic<T>, is_lock_free() которого возвращает true.

Рассуждение:

1. volatile может надежно работать на простых архитектурах (одноядерных, без кэша, ARM/Cortex-M), таких как STM32F2 или ATSAMG55, например, с Компилятор IAR. Но...
2. Он может не работать должным образом на более сложных архитектурах (многоядерных с кешем) и когда компилятор пытается выполнить определенные оптимизации (многие примеры в других ответах не повторяются).
3. atomic_flag и atomic_int (если is_lock_free() они должны) безопасно использовать где угодно, потому что они работают как volatile с добавленными барьерами памяти/синхронизацией при необходимости (избегая проблем в предыдущем пункте).
4. Причина, по которой я специально сказал, что вы должны использовать только те, у которых is_lock_free() равно true, заключается в том, что вы не можете остановить IRQ, как вы могли бы остановить поток. Нет, IRQ прерывает основной цикл и выполняет свою работу, он не может ждать блокировку мьютекса, потому что он блокирует основной цикл, которого должен ожидать.

Практическое примечание: я лично либо использую atomic_flag (единственный гарантированно работающий) для реализации своего рода спин-блокировки, где ISR отключается при обнаружении заблокированной блокировки, в то время как основной цикл всегда снова включает ISR после разблокировки. Или я использую очередь без блокировки с двойным счетчиком (SPSC - один производитель, один потребитель), используя этот atomit_int. (Имейте один счетчик чтения и один счетчик записи, вычтите, чтобы найти реальный счет. Подходит для UART и т. Д.)