Atomic int64_t на ARM Cortex M3

Question

Поскольку мой компилятор все еще не поддерживает C++ 11 и std :: atomic, я вынужден реализовать его вручную через пару ldrex-strex.

Мой вопрос: какой правильный способ «атомарно» читать-модифицировать-писать int64_t с помощью ldrex и strex?

Простое решение, как это не похоже на работу (один из STREXW возвращает 1 все время):

volatile int64_t value; 
int64_t temp; 

do 
{ 
    int32_t low = __LDREXW((uint32_t *)&value); 
    int32_t high = __LDREXW(((uint32_t *)&value)+1); 

    temp = (int64_t)low | ((int64_t)high<<32); 
    temp++;  

} while(__STREXW(temp, (uint32_t *)&value) | __STREXW(temp>>32, ((uint32_t *)&value)+1)); 

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

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

Answer 1

Это никогда не сработает, потому что вы не можете развести эксклюзивы таким образом. В реализации, локальный эксклюзивный монитор Cortex-M3 даже не отслеживает адрес - the exclusive reservation granule is the entire address space - поэтому предположение о слежении за каждым словом отдельно уже недействительно. Тем не менее, вы не должны даже рассмотреть любые детали реализации, так как архитектура уже явно исключает обратно к спине strex:

If two STREX instructions are executed without an intervening LDREX the second STREX returns a status value of 1. This means that:

• Every STREX must have a preceding LDREX associated with it in a given thread of execution.
• It is not necessary for every LDREX to have a subsequent STREX .

С Cortex-M3 (и ARMv7-M в целом) Безразлично» t есть ldrexd, как ARMv7-A, вам придется либо использовать отдельный замок для управления всеми обращениями к переменной, либо просто отключить прерывания вокруг read-modify-write. Если это вообще возможно, было бы лучше переделать вещи, не требующие атомарного 64-битного типа, в первую очередь, поскольку вы все равно только достигнете атомарности по отношению к другим потокам на одном ядре - вы просто не можете сделать 64 с точки зрения внешнего агента, как контроллер DMA.

Answer 2

Я бы просто посмотрел, как это делается gcc, и используйте одни и те же последовательности команд.

GCC 4.8.2 претензий реализовать std::atomic<int64_t> с is_lock_free() возвращает истину, даже с -mcpu=cortex-m3. К сожалению, на самом деле это не работает. Он делает код, который не связан или не работает, потому что нет реализации вспомогательных функций, которые он пытается использовать. (Спасибо @ Notlikethat за это.)

Here's the test code I tried. См. Старую версию этого ответа, если эта ссылка мертва. Я оставляю этот ответ на случай, если эта идея полезна для всех в связанных случаях, где gcc делает сделать полезный код.