Почему volatile не считается полезным в многопоточном программировании на C или C ++?

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

Однако примитивы, которые нам пришлось бы использовать для оставшихся свойств, также предоставляют те, которые выполняет volatile, поэтому в этом нет необходимости.

Для поточно-безопасного доступа к общим данным нам нужна гарантия того, что:

• чтение / запись действительно происходит (компилятор не просто сохранит значение в регистре и откладывает обновление основной памяти на гораздо более позднее время)
• что переупорядочивания не происходит. Предположим, что мы используем переменную volatile в качестве флага, чтобы указать, готовы ли некоторые данные к чтению. В нашем коде мы просто устанавливаем флаг после подготовки данных, поэтому все выглядит нормально. Но что, если инструкции переупорядочены так, чтобы флаг был установлен первым?

volatile действительно гарантирует первое очко. Это также гарантирует, что не происходит переупорядочения между разными изменяемыми операциями чтения / записи. Все volatile обращения к памяти будут происходить в том порядке, в котором они указаны. Это все, что нам нужно для того, для чего volatile предназначен: для управления регистрами ввода-вывода или оборудованием, отображаемым в память, но это не помогает нам в многопоточном коде, где объект volatile часто используется только для синхронизации доступа к энергонезависимым данным. Эти доступы все еще могут быть переупорядочены относительно volatile.

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

Однако барьеры памяти также гарантируют, что все ожидающие чтения / записи выполняются при достижении барьера, поэтому он фактически дает нам все необходимое само по себе, делая volatile ненужным. Мы можем просто полностью удалить квалификатор volatile.

Начиная с C ++ 11, атомарные переменные (std::atomic<T>) дают нам все соответствующие гарантии.

Вы также можете учесть это в документации ядра Linux.

Программисты на C часто использовали volatile для обозначения того, что переменная может быть изменена вне текущего потока выполнения; в результате у них иногда возникает соблазн использовать его в коде ядра, когда используются общие структуры данных. Другими словами, они, как известно, рассматривают изменчивые типы как своего рода простую атомарную переменную, которой они не являются. Использование volatile в коде ядра почти никогда не бывает правильным; этот документ описывает почему.

Ключевой момент, который следует понять в отношении volatile, заключается в том, что его цель - подавить оптимизацию, что почти никогда не является тем, чем действительно хочется заниматься. В ядре необходимо защищать совместно используемые структуры данных от нежелательного одновременного доступа, а это совсем другая задача. Процесс защиты от нежелательного параллелизма также позволит избежать почти всех проблем, связанных с оптимизацией, более эффективным способом.

Как и volatile, примитивы ядра, которые делают одновременный доступ к данным безопасным (спин-блокировки, мьютексы, барьеры памяти и т. Д.), Предназначены для предотвращения нежелательной оптимизации. Если они используются правильно, нет необходимости использовать и volatile. Если volatile по-прежнему необходим, почти наверняка где-то в коде есть ошибка. В правильно написанном коде ядра volatile может только замедлить работу.

Рассмотрим типичный блок кода ядра:

spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

Если весь код следует правилам блокировки, значение shared_data не может неожиданно измениться, пока удерживается the_lock. Любой другой код, который может захотеть поиграть с этими данными, будет ждать блокировки. Примитивы спин-блокировки действуют как барьеры памяти - они явно написаны для этого - это означает, что доступ к данным не будет оптимизирован для них. Таким образом, компилятор может подумать, что он знает, что будет в shared_data, но вызов spin_lock (), поскольку он действует как барьер памяти, заставит его забыть все, что он знает. Проблем с оптимизацией доступа к этим данным не возникнет.

Если бы shared_data была объявлена ​​изменчивой, блокировка все равно была бы необходима. Но компилятор также не сможет оптимизировать доступ к shared_data внутри критического раздела, когда мы знаем, что никто другой не может с ним работать. Пока блокировка удерживается, shared_data не является изменчивым. При работе с общими данными правильная блокировка делает изменчивые данные ненужными - и потенциально опасными.

Класс энергозависимой памяти изначально предназначался для регистров ввода-вывода с отображением в память. Внутри ядра доступ к регистрам также должен быть защищен блокировками, но также не следует, чтобы компилятор «оптимизировал» доступ к регистрам в критическом разделе. Но внутри ядра доступ к памяти ввода / вывода всегда осуществляется через функции доступа; доступ к памяти ввода-вывода напрямую через указатели не одобряется и работает не на всех архитектурах. Эти аксессоры написаны для предотвращения нежелательной оптимизации, поэтому, опять же, в volatile нет необходимости.

Другая ситуация, в которой может возникнуть соблазн использовать volatile, - это когда процессор занят ожиданием значения переменной. Правильный способ выполнения активного ожидания:

while (my_variable != what_i_want)
    cpu_relax();

Вызов cpu_relax () может снизить энергопотребление ЦП или уступить место двухпоточному процессору; он также служит барьером для памяти, поэтому, опять же, volatile не нужен. Конечно, ожидание в ожидании - это вообще антисоциальный акт с самого начала.

Есть еще несколько редких ситуаций, когда volatile имеет смысл в ядре:

• Вышеупомянутые функции доступа могут использовать volatile на архитектурах, где прямой доступ к памяти ввода-вывода действительно работает. По сути, каждый вызов метода доступа сам по себе становится небольшим критическим разделом и гарантирует, что доступ происходит так, как ожидал программист.

• Встроенный ассемблерный код, который изменяет память, но не имеет других видимых побочных эффектов, рискует быть удаленным GCC. Добавление ключевого слова volatile в операторы asm предотвратит это удаление.

• Переменная jiffies отличается тем, что каждый раз при обращении к ней может иметь другое значение, но ее можно прочитать без какой-либо специальной блокировки. Таким образом, jiffies могут быть непостоянными, но добавление других переменных этого типа категорически не одобряется. В этом отношении Джиффис считается «глупым наследием» (слова Линуса); починить это было бы труднее, чем оно того стоит.

• Указатели на структуры данных в когерентной памяти, которые могут быть изменены устройствами ввода-вывода, иногда вполне законно могут быть энергозависимыми. Кольцевой буфер, используемый сетевым адаптером, где этот адаптер изменяет указатели, чтобы указать, какие дескрипторы были обработаны, является примером такого типа ситуации.

Для большей части кода ни одно из приведенных выше обоснований для volatile не применимо. В результате использование volatile, вероятно, будет рассматриваться как ошибка и потребует дополнительной проверки кода. Разработчики, которые склонны использовать volatile, должны сделать шаг назад и подумать о том, чего они на самом деле пытаются достичь.

Я не думаю, что вы ошибаетесь - volatile необходимо, чтобы гарантировать, что поток A увидит изменение значения, если значение будет изменено чем-то другим, кроме потока A. Насколько я понимаю, volatile - это в основном способ сообщить компилятор «не кэшируйте эту переменную в регистре, вместо этого обязательно всегда читать / записывать ее из оперативной памяти при каждом доступе».

Путаница возникает из-за того, что volatile недостаточно для реализации ряда вещей. В частности, современные системы используют несколько уровней кэширования, современные многоядерные процессоры делают некоторые причудливые оптимизации во время выполнения, а современные компиляторы делают некоторые причудливые оптимизации во время компиляции, и все это может привести к различным побочным эффектам, проявляющимся в разных заказ из того порядка, который вы ожидали, если бы вы просто посмотрели исходный код.

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

Лично мое основное (единственное?) Использование флага volatile - это логическое значение "pleaseGoAwayNow". Если у меня есть рабочий поток, который непрерывно зацикливается, я заставлю его проверять изменчивое логическое значение на каждой итерации цикла и выходить, если логическое значение когда-либо истинно. Затем основной поток может безопасно очистить рабочий поток, установив логическое значение true, а затем вызвать pthread_join (), чтобы дождаться завершения рабочего потока.

volatile полезен (хотя и недостаточен) для реализации базовой конструкции мьютекса спин-блокировки, но как только он у вас есть (или что-то более качественное), вам больше не понадобится volatile.

Типичный способ многопоточного программирования - не защищать каждую совместно используемую переменную на машинном уровне, а скорее вводить защитные переменные, которые направляют выполнение программы. Вместо volatile bool my_shared_flag; у вас должно быть

pthread_mutex_t flag_guard_mutex; // contains something volatile
bool my_shared_flag;

Это не только инкапсулирует «жесткую часть», но и принципиально необходимо: C не включает атомарные операции, необходимые для реализации мьютекса; у него есть только volatile, чтобы дать дополнительные гарантии в отношении обычных операций.

Теперь у вас есть что-то вроде этого:

pthread_mutex_lock( &flag_guard_mutex );
my_local_state = my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

pthread_mutex_lock( &flag_guard_mutex ); // may alter my_shared_flag
my_shared_flag = ! my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

my_shared_flag не обязательно должен быть изменчивым, несмотря на то, что он не кэшируется, потому что

1. Другой поток имеет к нему доступ.
2. Meaning a reference to it must have been taken sometime (with the & operator).
   • (Or a reference was taken to a containing structure)
3. pthread_mutex_lock - это библиотечная функция.
4. Это означает, что компилятор не может определить, получает ли pthread_mutex_lock эту ссылку.
5. Это означает, что компилятор должен предполагать, что pthread_mutex_lock изменяет общий флаг!
6. Значит, переменную нужно перезагрузить из памяти. volatile, хотя и имеет значение в этом контексте, является посторонним.

Ваше понимание действительно неверно.

Свойство изменчивых переменных: «чтение и запись в эту переменную являются частью воспринимаемого поведения программы». Это означает, что эта программа работает (при наличии соответствующего оборудования):

int volatile* reg=IO_MAPPED_REGISTER_ADDRESS;
*reg=1; // turn the fuel on
*reg=2; // ignition
*reg=3; // release
int x=*reg; // fire missiles

Проблема в том, что это не то свойство, которое нам нужно от чего-либо поточно-ориентированного.

Например, поточно-ориентированный счетчик будет просто (код, подобный ядру Linux, не знаю эквивалента C ++ 0x):

atomic_t counter;

...
atomic_inc(&counter);

Это атомарно, без барьера памяти. При необходимости их следует добавить. Добавление volatile, вероятно, не поможет, потому что оно не будет связывать доступ к соседнему коду (например, с добавлением элемента в список, который подсчитывает счетчик). Конечно, вам не нужно видеть, как счетчик увеличивается за пределами вашей программы, и оптимизация все еще желательна, например.

atomic_inc(&counter);
atomic_inc(&counter);

все еще можно оптимизировать до

atomically {
  counter+=2;
}

если оптимизатор достаточно умен (он не меняет семантику кода).

Чтобы ваши данные были согласованными в параллельной среде, вам необходимо выполнить два условия:

1) Атомарность, т.е. если я читаю или записываю некоторые данные в память, эти данные читаются / записываются за один проход и не могут быть прерваны или оспорены, например, из-за переключения контекста.

2) Согласованность, т.е. порядок операций чтения / записи должен быть виден одинаковым для нескольких параллельных сред - будь то потоки, машины и т. Д.

volatile не соответствует ни одному из вышеперечисленных - или, в частности, стандарту c или c ++ относительно того, как должен вести себя volatile, не входит ни одно из вышеперечисленного.

На практике это еще хуже, поскольку некоторые компиляторы (например, компилятор Intel Itanium) действительно пытаются реализовать некоторый элемент безопасного поведения при одновременном доступе (например, путем обеспечения ограждений памяти), однако между реализациями компилятора нет согласованности, и, более того, стандарт не требует этого. реализации в первую очередь.

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

c # и java AFAIK исправляют это, заставляя volatile придерживаться 1) и 2), однако то же самое нельзя сказать о компиляторах c / c ++, поэтому в основном поступайте с ним так, как считаете нужным.

Для более глубокого (хотя и не беспристрастного) обсуждения этого вопроса прочтите это

В FAQ comp.programming.threads есть классическое объяснение Дэйва Бутенхофа:

В56: Почему мне не нужно объявлять общие переменные VOLATILE?

Однако меня беспокоят случаи, когда и компилятор, и библиотека потоков выполняют свои соответствующие спецификации. Соответствующий компилятор C может глобально выделить некоторую общую (энергонезависимую) переменную в регистр, который сохраняется и восстанавливается по мере передачи ЦП от потока к потоку. Каждый поток будет иметь собственное частное значение для этой общей переменной, чего мы не хотим от общей переменной.

В некотором смысле это правда, если компилятор знает достаточно о соответствующих областях действия переменной и функций pthread_cond_wait (или pthread_mutex_lock). На практике большинство компиляторов не будут пытаться сохранять регистровые копии глобальных данных при вызове внешней функции, потому что слишком сложно понять, может ли процедура каким-либо образом иметь доступ к адресу данных.

Так что да, это правда, что компилятор, который строго (но очень агрессивно) соответствует ANSI C, может не работать с несколькими потоками без volatile. Но лучше кому-нибудь это исправить. Потому что любая СИСТЕМА (то есть, прагматически комбинация ядра, библиотек и компилятора C), которая не обеспечивает гарантии когерентности памяти POSIX, НЕ СООТВЕТСТВУЕТ стандарту POSIX. Период. Система НЕ МОЖЕТ требовать, чтобы вы использовали volatile для общих переменных для правильного поведения, потому что POSIX требует только, чтобы функции синхронизации POSIX были необходимы.

Так что, если ваша программа ломается из-за того, что вы не использовали volatile, это ОШИБКА. Это может быть не ошибка в C, или ошибка в библиотеке потоков, или ошибка в ядре. Но это ошибка СИСТЕМЫ, и один или несколько из этих компонентов должны работать, чтобы исправить ее.

Вы не хотите использовать изменчивую переменную, потому что в любой системе, где это имеет значение, это будет намного дороже, чем правильная энергонезависимая переменная. (ANSI C требует "точек последовательности" для изменчивых переменных в каждом выражении, тогда как POSIX требует их только при операциях синхронизации - многопоточное приложение с интенсивными вычислениями будет видеть значительно большую активность памяти с использованием volatile, и, в конце концов, именно активность памяти действительно замедляет вас.)

/ --- [Дэйв Бутенхоф] ----------------------- [[email protected]] --- \
| Корпорация цифрового оборудования 110 Spit Brook Rd ZKO2-3 / Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
----------------- [Лучшая жизнь за счет параллелизма] ---------- ------ /

Г-н Бутенхоф во многом освещает те же вопросы в это сообщение usenet:

Использование «volatile» недостаточно для обеспечения надлежащей видимости памяти или синхронизации между потоками. Достаточно использования мьютекса, и, за исключением использования различных непереносимых альтернатив машинного кода (или более тонких последствий правил памяти POSIX, которые гораздо сложнее применять в целом, как объяснялось в моем предыдущем посте), мьютекс НЕОБХОДИМ.

Поэтому, как объяснил Брайан, использование volatile ничего не дает, кроме как помешать компилятору делать полезные и желательные оптимизации, не оказывая никакой помощи в создании «поточно-ориентированного» кода. Вы, конечно, можете объявлять все, что хотите, как «изменчивое» - в конце концов, это законный атрибут хранения ANSI C. Только не ждите, что это решит за вас какие-либо проблемы с синхронизацией потоков.

Все это в равной степени применимо и к C ++.

Это все, что делает «volatile»: «Эй, компилятор, эта переменная может измениться В ЛЮБОЙ МОМЕНТ (на любом такте), даже если на нее НЕТ ЛОКАЛЬНЫХ ИНСТРУКЦИЙ. НЕ кэшируйте это значение в регистре».

Это ОНО. Он сообщает компилятору, что ваше значение является изменчивым - это значение может быть изменено в любой момент внешней логикой (другим потоком, другим процессом, ядром и т. Д.). Он существует более или менее исключительно для подавления оптимизаций компилятора, которые будут молча кэшировать значение в регистре, которое по своей природе небезопасно для кеш-памяти EVER.

Вы можете встретить такие статьи, как «Доктор Доббс», в которых изменчивость рассматривается как панацея для многопоточного программирования. Его подход не лишен достоинств, но он имеет фундаментальный недостаток, заключающийся в том, что пользователи объекта несут ответственность за его потокобезопасность, что, как правило, имеет те же проблемы, что и другие нарушения инкапсуляции.

Согласно моему старому стандарту C, «То, что составляет доступ к объекту с изменяемым типом, определяется реализацией». Таким образом, разработчики компилятора C могли выбрать «изменчивый», означающий «потокобезопасный доступ в многопроцессорной среде». Но они этого не сделали.

Вместо этого операции, необходимые для обеспечения потоковой безопасности критического раздела в многоядерной многопроцессорной среде с общей памятью, были добавлены в качестве новых функций, определяемых реализацией. И, освобожденные от требования, чтобы «изменчивый» обеспечивал атомарный доступ и упорядочение доступа в многопроцессорной среде, авторы компилятора отдали приоритет сокращению кода над «изменчивой» семантикой, зависящей от исторической реализации.

Это означает, что такие вещи, как «изменчивые» семафоры вокруг критических участков кода, которые не работают на новом оборудовании с новыми компиляторами, могли когда-то работать со старыми компиляторами на старом оборудовании, а старые примеры иногда не ошибочны, а просто старые.