Является ли std :: atomic <T>безопасным с прерываниями, когда std :: atomic <T>:: is_always_lock_free имеет значение false?

Question

Во встроенной (ARM) среде без ОС, если я использую прерывания, есть ли вероятность тупиковой ситуации при использовании std::atomic<T>?Если так, то как?

Как правило, в любой момент управление может быть прервано для обработки прерывания.В частности, если кто-то наивно должен иметь мьютекс и хочет использовать его для «безопасной» переменной, он может заблокировать, записать и разблокировать, а затем заблокировать, прочитать и разблокировать в другом месте.Но если чтение выполняется в режиме прерывания, вы можете заблокировать, прервать, заблокировать => взаимоблокировку.

В частности, у меня есть std::atomic<int>, для которого is_always_lock_free равно false.Стоит ли беспокоиться по поводу тупиковой ситуации?Когда я смотрю на сгенерированную сборку, запись 42 выглядит следующим образом:

bl __sync_synchronize
mov r3, #42
str r3, [sp, #4]
bl __sync_synchronize

, которая, кажется, не блокируется.ASM для чтения значения аналогичен.Является ли (возможной) блокировка для более сложных операций, например, exchange?

Answer 1

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

Какое ядро ​​ARM вы используете?На ARM Cortex-A7 следующее печатает true для обоих.

#include <iostream>
#include <atomic>

int main()
{
   std::atomic<int> x;
   std::cout << std::boolalpha << x.is_lock_free() << std::endl;
   std::cout << std::atomic<int>::is_always_lock_free << std::endl;
}

Я бы ожидал, что std::atomic<int> будет реализован без блокировок в большинстве случаев, если не во всех, на ARM, и, конечно, из предоставленной вами сборки он не использует блокировку.