барьер памяти и atomic_t в Linux

Недавно я читал несколько кодов пространства ядра Linux, я вижу это

uint64_t used;
uint64_t blocked;

used = atomic64_read(&g_variable->used);       //#1
barrier();                                     //#2
blocked = atomic64_read(&g_variable->blocked); //#3

Какова семантика этого фрагмента кода? Убедитесь, что №1 выполняется перед №3 по №2. Но я немного запутался, потому что

#A В 64-битной платформе макрос atomic64_read расширен до

used = (&g_variable->used)->counter           // where counter is volatile.

. В 32-битной платформе он был преобразован для использования блокировки cmpxchg8b . Я предполагаю, что эти два имеют одинаковую семантику, и для 64-битной версии, я думаю, это означает:

1. все или ничего , мы можем исключить случай, когда адрес не выровнен и размер слова больше, чем собственный размер слова процессора.
2. без оптимизации , принудительное чтение ЦП из области памяти.

atomic64_read не имеет семантики для сохранения порядка чтения !!! см. this

#B the Макрос барьера определен как

/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

Из вики этот просто предотвращает компилятор gcc от переупорядочивания чтения и записи.

Я не понимаю, как это делается отключить оптимизацию переупорядочения для ЦП? Вдобавок, могу ли я думать, что макрос барьера - это полный забор?