Atomic int64_t su ARM Cortex M3

Question

Dato che il mio compilatore non supporta ancora C++ 11 e std :: atomic, sono costretto a implementarlo manualmente tramite la coppia ldrex-strex.

La mia domanda è: qual è il modo corretto di "atomicamente" leggere-modificare-scrivere int64_t con ldrex e strex?

soluzione semplice come questo non sembra funzionare (uno dei STREXW restituisce 1 per tutto il tempo):

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)); 

non ho trovato nulla circa parecchi LDREX sequenziale o istruzioni STREX indicando varie strade il manuale ma mi è sembrato che fosse permesso.

In caso contrario più thread non sarebbero in grado di modificare due diverse variabili atomiche in alcuni scenari.

Answer 1

Questo non funzionerà mai, perché non è possibile nidificare esclusive in questo modo. Per quanto riguarda l'implementazione, il monitor esclusivo locale Cortex-M3 non tiene nemmeno traccia di un indirizzo - the exclusive reservation granule is the entire address space - quindi l'ipotesi di tracciare ogni parola separatamente è già valida. Tuttavia, non c'è nemmeno bisogno di prendere in considerazione eventuali dettagli di implementazione, perché l'architettura regole già esplicitamente il back-to-back 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 .

Dal Cortex-M3 (e ARMv7-M in generale) doesn' t avere ldrexd come ARMv7-A, dovrai usare un blocco separato per controllare tutti gli accessi alla variabile, o semplicemente disabilitare gli interrupt attorno al read-modify-write. Se possibile, sarebbe davvero meglio riprogettare le cose non avendo bisogno di un tipo atomico a 64 bit, dato che si otterrebbe comunque solo l'atomicità rispetto ad altri thread sullo stesso core - semplicemente non si può fare 64 operazione bit atomica dal punto di vista di un agente esterno come un controller DMA.

Answer 2

Vorrei solo vedere come gcc lo fa e utilizzare le stesse sequenze di istruzioni.

gcc 4.8.2 pretese per implementare std::atomic<int64_t> con is_lock_free() restituendo vero, anche con -mcpu=cortex-m3. Sfortunatamente, non funziona davvero. Rende il codice che non si collega o non funziona, perché non c'è implementazione delle funzioni di aiuto che tenta di usare. (Grazie a @Notlikethat per averlo provato.)

Here's the test code I tried. Vedi una vecchia versione di questa risposta se quel collegamento è morto. Lascio questa risposta nel caso in cui l'idea sia utile per chiunque nei casi correlati in cui gcc fa codice.