Почему существует изменчивый?

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

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

Раньше я работал с двухпортовой оперативной памятью в многопроцессорной системе на прямом C. Мы использовали аппаратно управляемое 16-битное значение в качестве семафора, чтобы узнать, когда другой парень закончил. По сути, мы сделали это:

void waitForSemaphore()
{
   volatile uint16_t* semPtr = WELL_KNOWN_SEM_ADDR;/*well known address to my semaphore*/
   while ((*semPtr) != IS_OK_FOR_ME_TO_PROCEED);
}

Без volatile оптимизатор видит цикл как бесполезный (этот парень никогда не устанавливает значение! Он чокнутый, избавьтесь от этого кода!), И мой код продолжился бы, не получив семафор, что впоследствии вызовет проблемы.

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

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

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

Из статьи Дэна Сакса «Неустойчивый как обещание»:

(...) a volatile object is one whose value might change spontaneously. That is, when you declare an object to be volatile, you're telling the compiler that the object might change state even though no statements in the program appear to change it."

Вот ссылки на три его статьи о ключевом слове volatile:

• Разумно используйте volatile
• Поместите летучие вещества точно
• Неустойчивый как обещание

Некоторые процессоры имеют регистры с плавающей запятой, точность которых превышает 64 бита (например, 32-битный x86 без SSE, см. Комментарий Питера). Таким образом, если вы выполните несколько операций с числами с двойной точностью, вы фактически получите ответ с более высокой точностью, чем если бы вы усекали каждый промежуточный результат до 64 бит.

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

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

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

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

Большое приложение, над которым я работал в начале 1990-х, содержало обработку исключений на основе C с использованием setjmp и longjmp. Ключевое слово volatile было необходимо для переменных, значения которых необходимо было сохранить в блоке кода, который служил предложением «catch», чтобы эти переменные не сохранялись в регистрах и не стирались с помощью longjmp.

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

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

template <typename T> 
class Foo {
  std::enable_if_t<sizeof(T)==4, void> f(T& t) 
  { std::cout << 1 << t; }
  void f(T volatile& t) 
  { std::cout << 2 << const_cast<T&>(t); }

  void bar() { T t; f(t); }
};

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

Обратите внимание, что код на самом деле никогда не зависит от доступа к памяти volatile.

Вы ДОЛЖНЫ использовать volatile при реализации структур данных без блокировки. В противном случае компилятор может оптимизировать доступ к переменной, что изменит семантику.

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

Например, вот как InterlockedIncrement объявляется в Win32 API:

LONG __cdecl InterlockedIncrement(
  __inout  LONG volatile *Addend
);

В стандарте C одно из мест использования volatile - это обработчик сигналов. Фактически, в стандарте C все, что вы можете безопасно сделать в обработчике сигналов, - это изменить переменную volatile sig_atomic_t или быстро выйти. Действительно, AFAIK, это единственное место в стандарте C, в котором требуется использование volatile, чтобы избежать неопределенного поведения.

ISO/IEC 9899:2011 §7.14.1.1 The signal function

¶5 If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, the quick_exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. Furthermore, if such a call to the signal function results in a SIG_ERR return, the value of errno is indeterminate.²⁵²⁾

²⁵²⁾ If any signal is generated by an asynchronous signal handler, the behavior is undefined.

Это означает, что в стандарте C вы можете написать:

static volatile sig_atomic_t sig_num = 0;

static void sig_handler(int signum)
{
    signal(signum, sig_handler);
    sig_num = signum;
}

и не более того.

POSIX гораздо более снисходительно относится к тому, что вы можете делать в обработчике сигналов, но все же есть ограничения (и одно из ограничений заключается в том, что стандартную библиотеку ввода-вывода - printf() и др. - нельзя безопасно использовать).

Ключевое слово volatile предназначено для предотвращения применения компилятором любых оптимизаций к объектам, которые могут изменяться способами, которые не могут быть определены компилятором.

Объекты, объявленные как volatile, исключаются из оптимизации, поскольку их значения могут быть изменены кодом, выходящим за рамки текущего кода, в любое время. Система всегда считывает текущее значение объекта volatile из области памяти, а не сохраняет его значение во временном регистре в момент запроса, даже если предыдущая инструкция запрашивала значение у того же объекта.

Рассмотрим следующие случаи

1) Глобальные переменные, измененные подпрограммой обслуживания прерывания вне области видимости.

2) Глобальные переменные в многопоточном приложении.

Если мы не используем квалификатор volatile, могут возникнуть следующие проблемы

1) Код может работать не так, как ожидалось, когда включена оптимизация.

2) Код может работать не так, как ожидалось, когда прерывания разрешены и используются.

Неустойчивый: лучший друг программиста

https://en.wikipedia.org/wiki/Volatile_(computer_programming)

Я должен вам напомнить, что в функции обработчика сигналов, если вы хотите получить доступ / изменить глобальную переменную (например, пометить ее как exit = true), вы должны объявить эту переменную как «изменчивую».

Кажется, ваша программа работает даже без ключевого слова volatile? Возможно, причина в этом:

Как упоминалось ранее, ключевое слово volatile помогает в таких случаях, как

volatile int* p = ...;  // point to some memory
while( *p!=0 ) {}  // loop until the memory becomes zero

Но, похоже, почти нет эффекта после вызова внешней или не встроенной функции. Например.:

while( *p!=0 ) { g(); }

Тогда с volatile или без него будет получен почти такой же результат.

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

Но будьте осторожны, когда ваша функция g () станет встроенной (либо из-за явных изменений, либо из-за хитрости компилятора / компоновщика), ваш код может сломаться, если вы забыли ключевое слово volatile!

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

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

Какие именно детали секвенирования важны, зависит от целевой платформы и области применения. Вместо того, чтобы предоставлять особенно подробный контроль, Стандарт выбрал простую модель: если последовательность обращений выполняется с lvalue, не отвечающим требованиям volatile, компилятор может переупорядочить и объединить их по своему усмотрению. Если действие выполняется с lvalue, соответствующим volatile, качественная реализация должна предлагать любые дополнительные гарантии упорядочения, которые могут потребоваться для кода, нацеленного на ее предполагаемую платформу и поле приложения, не требуя от программистов использования нестандартного синтаксиса.

К сожалению, вместо того, чтобы определять, какие гарантии понадобятся программистам, многие компиляторы вместо этого предпочли предложить минимум гарантий, предусмотренных Стандартом. Это делает volatile гораздо менее полезным, чем следовало бы. В gcc или clang, например, программист, которому необходимо реализовать базовый «мьютекс передачи обслуживания» [такой, когда задача, которая получила и освободила мьютекс, не будет делать этого снова, пока это не сделает другая задача], должен выполнить из четырех вещей:

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

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

3. Используйте уровень оптимизации 0, чтобы компилятор сгенерировал код, как если бы все объекты, не отвечающие требованиям register, были volatile.

4. Используйте специфичные для gcc директивы.

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

5. Убедитесь, что запись, отвечающая требованиям volatile, выполняется везде, где требуется получение или выпуск.

Для получения базового «мьютекса передачи» требуется чтение volatile (чтобы увидеть, готов ли он), и также не требуется запись volatile (другая сторона не будет пытаться повторно получить его, пока он не будет возвращен), но необходимость выполнять бессмысленную запись volatile все же лучше, чем любой из вариантов, доступных в gcc или clang.

В других ответах уже упоминается об избежании некоторой оптимизации, чтобы:

• использовать регистры с отображением в память (или "MMIO")
• писать драйверы устройств
• облегчить отладку программ
• сделать вычисления с плавающей запятой более детерминированными

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

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

Энергозависимая запись похожа на операцию вывода (например, printf или использование cout): значение, кажется, передается вне программы, поэтому, если значение зависит от вычисления, его необходимо завершить до.

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

Без volatile ваши вычисления могут быть запущены компилятором раньше, так как ничто не помешало бы переупорядочить вычисления с такими функциями, как измерение времени.

Все ответы отличные. Но в довершение всего я хотел бы привести пример.

Ниже представлена ​​небольшая программа cpp:

#include <iostream>

int x;

int main(){
    char buf[50];
    x = 8;

    if (x == 8)
        printf("x is 8\n");
    else
        sprintf(buf, "x is not 8\n");

    x=1000;
    while(x > 5)
        x--;
    return 0;
}

Теперь давайте сгенерируем сборку приведенного выше кода (и я вставлю только те части сборки, которые здесь важны):

Команда для генерации сборки:

g++ -S -O3 -c -fverbose-asm -Wa,-adhln assembly.cpp

И сборка:

main:
.LFB1594:
    subq    , %rsp    #,
    .seh_stackalloc 40
    .seh_endprologue
 # assembly.cpp:5: int main(){
    call    __main   #
 # assembly.cpp:10:         printf("x is 8\n");
    leaq    .LC0(%rip), %rcx     #,
 # assembly.cpp:7:     x = 8;
    movl    , x(%rip)  #, x
 # assembly.cpp:10:         printf("x is 8\n");
    call    _ZL6printfPKcz.constprop.0   #
 # assembly.cpp:18: }
    xorl    %eax, %eax   #
    movl    , x(%rip)  #, x
    addq    , %rsp    #,
    ret 
    .seh_endproc
    .p2align 4,,15
    .def    _GLOBAL__sub_I_x;   .scl    3;  .type   32; .endef
    .seh_proc   _GLOBAL__sub_I_x

Вы можете видеть в сборке, что код сборки не был сгенерирован для sprintf, потому что компилятор предположил, что x не будет изменяться вне программы. То же самое и с петлей while. Цикл while был полностью удален из-за оптимизации, поскольку компилятор увидел в нем бесполезный код и, таким образом, напрямую присвоил 5x (см. movl , x(%rip)).

Проблема возникает, если внешний процесс / оборудование изменит значение x где-то между x = 8; и if (x == 8). Мы ожидали, что блок else будет работать, но, к сожалению, компилятор вырезал эту часть.

Теперь, чтобы решить эту проблему, в assembly.cpp давайте изменим int x; на volatile int x; и быстро увидим сгенерированный ассемблерный код:

main:
.LFB1594:
    subq    4, %rsp   #,
    .seh_stackalloc 104
    .seh_endprologue
 # assembly.cpp:5: int main(){
    call    __main   #
 # assembly.cpp:7:     x = 8;
    movl    , x(%rip)  #, x
 # assembly.cpp:9:     if (x == 8)
    movl    x(%rip), %eax    # x, x.1_1
 # assembly.cpp:9:     if (x == 8)
    cmpl    , %eax     #, x.1_1
    je  .L11     #,
 # assembly.cpp:12:         sprintf(buf, "x is not 8\n");
    leaq    32(%rsp), %rcx   #, tmp93
    leaq    .LC0(%rip), %rdx     #,
    call    _ZL7sprintfPcPKcz.constprop.0    #
.L7:
 # assembly.cpp:14:     x=1000;
    movl    00, x(%rip)   #, x
 # assembly.cpp:15:     while(x > 5)
    movl    x(%rip), %eax    # x, x.3_15
    cmpl    , %eax     #, x.3_15
    jle .L8  #,
    .p2align 4,,10
.L9:
 # assembly.cpp:16:         x--;
    movl    x(%rip), %eax    # x, x.4_3
    subl    , %eax     #, _4
    movl    %eax, x(%rip)    # _4, x
 # assembly.cpp:15:     while(x > 5)
    movl    x(%rip), %eax    # x, x.3_2
    cmpl    , %eax     #, x.3_2
    jg  .L9  #,
.L8:
 # assembly.cpp:18: }
    xorl    %eax, %eax   #
    addq    4, %rsp   #,
    ret 
.L11:
 # assembly.cpp:10:         printf("x is 8\n");
    leaq    .LC1(%rip), %rcx     #,
    call    _ZL6printfPKcz.constprop.1   #
    jmp .L7  #
    .seh_endproc
    .p2align 4,,15
    .def    _GLOBAL__sub_I_x;   .scl    3;  .type   32; .endef
    .seh_proc   _GLOBAL__sub_I_x

Здесь вы можете видеть, что коды сборки для цикла sprintf, printf и while были сгенерированы. Преимущество состоит в том, что если переменная x изменяется какой-либо внешней программой или оборудованием, часть кода sprintf будет выполнена. Точно так же цикл while теперь можно использовать для ожидания занятости.

Я хотел бы процитировать слова Херба Саттера из его GotW # 95, которые могут помочь понять значение переменных volatile:

C++volatile variables (which have no analog in languages like C# and Java) are always beyond the scope of this and any other article about the memory model and synchronization. That’s because C++volatile variables aren’t about threads or communication at all and don’t interact with those things. Rather, a C++volatile variable should be viewed as portal into a different universe beyond the language — a memory location that by definition does not obey the language’s memory model because that memory location is accessed by hardware (e.g., written to by a daughter card), have more than one address, or is otherwise “strange” and beyond the language. So C++volatile variables are universally an exception to every guideline about synchronization because are always inherently “racy” and unsynchronizable using the normal tools (mutexes, atomics, etc.) and more generally exist outside all normal of the language and compiler including that they generally cannot be optimized by the compiler (because the compiler isn’t allowed to know their semantics; a volatile int vi; may not behave anything like a normal int, and you can’t even assume that code like vi = 5; int read_back = vi; is guaranteed to result in read_back == 5, or that code like int i = vi; int j = vi; that reads vi twice will result in i == j which will not be true if vi is a hardware counter for example).