Правильно ли реализован этот барьер памяти?
Я читаю устаревший код C ++, где барьер памяти определен, как показано ниже. Основными ОС являются linux и vxworks. Компиляторы gcc (gcc от WindRiver).
#if((KCompilerGNU)||(kCompilerWindRiver))
#define MEMORY_BARRIER __asm__ volatile("nop\n");
#else
#define MEMORY_BARRIER __asm nop;
#endif
Но я не вижу, как работает неоперативная операция для создания барьера памяти? Или это просто ошибка реализации?
Решение
Это барьер компилятора, а не полный аппаратный барьер памяти. То есть он предназначен для непрозрачного вызова, который компилятор не может оптимизировать, но он не оказывает никакого влияния на оборудование с точки зрения переупорядочения памяти1. Для этой цели он может быть определен правильно, если рассматриваемые компиляторы действительно обрабатывают блоки asm как непрозрачные (например, блоки gcc asm имеют специальные правила для точного определения того, что может измениться в блоке и т. Д.).
Возможно, будет уместно назвать его полным барьером памяти (который обычно подавляет перекомпоновку компилятора и оборудования), если вы знаете, что оборудование, на которое ориентирован этот код, имеет сильную модель памяти, которая никогда не переупорядочивает операции с памятью.
1 Тем не менее, такой барьер все еще может быть достаточно в случае, если программа является однопоточной или машина не демонстрирует интересные переупорядочения (например, простой в порядке, не спекулятивный ЦП или однопроцессорная система).
Другие решения
Других решений пока нет …