¿Por qué existe volátil?

¿Qué hace la volatilepalabra clave? En C ++, ¿qué problema resuelve?

En mi caso, nunca lo he necesitado a sabiendas.

volatile es necesario si está leyendo desde un punto en la memoria que, por ejemplo, un proceso / dispositivo / lo que sea completamente separado en lo que pueda escribir.

Solía ​​trabajar con ram de doble puerto en un sistema multiprocesador en línea C. Usamos un valor de 16 bits administrado por hardware como semáforo para saber cuándo había terminado el otro tipo. Esencialmente hicimos esto:

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

Sin volatile, el optimizador ve el ciclo como inútil (¡El tipo nunca establece el valor! ¡Está loco, deshazte de ese código!) Y mi código continuaría sin haber adquirido el semáforo, causando problemas más adelante.

volatilees necesario cuando se desarrollan sistemas embebidos o controladores de dispositivos, donde necesita leer o escribir un dispositivo de hardware mapeado en memoria. El contenido de un registro de dispositivo particular puede cambiar en cualquier momento, por lo que necesita la volatilepalabra clave para asegurarse de que el compilador no optimice dichos accesos.

Algunos procesadores tienen registros de coma flotante que tienen más de 64 bits de precisión (por ejemplo, 32 bits x86 sin SSE, vea el comentario de Peter). De esa forma, si ejecuta varias operaciones con números de doble precisión, obtendrá una respuesta de mayor precisión que si truncara cada resultado intermedio a 64 bits.

Esto suele ser genial, pero significa que dependiendo de cómo el compilador asignó registros e hizo optimizaciones, tendrá resultados diferentes para las mismas operaciones en las mismas entradas. Si necesita coherencia, puede forzar que cada operación regrese a la memoria utilizando la palabra clave volátil.

También es útil para algunos algoritmos que no tienen sentido algebraico pero reducen el error de coma flotante, como la suma de Kahan. Algebraicamente es un nop, por lo que a menudo se optimizará incorrectamente a menos que algunas variables intermedias sean volátiles.

De un artículo de "Volátil como promesa" de Dan Saks:

(...) un objeto volátil es aquel cuyo valor puede cambiar espontáneamente. Es decir, cuando declaras que un objeto es volátil, le estás diciendo al compilador que el objeto podría cambiar de estado a pesar de que no parece haber ninguna declaración en el programa que lo cambie ".

Aquí hay enlaces a tres de sus artículos sobre la volatilepalabra clave:

• Usar volátil juiciosamente
• Coloque volátil con precisión
• Volátil como una promesa

DEBE usar volátiles al implementar estructuras de datos sin bloqueo. De lo contrario, el compilador es libre de optimizar el acceso a la variable, lo que cambiará la semántica.

Para decirlo de otra manera, volátil le dice al compilador que los accesos a esta variable deben corresponder a una operación de lectura / escritura de memoria física.

Por ejemplo, así es como se declara InterlockedIncrement en la API Win32:

LONG __cdecl InterlockedIncrement(
  __inout  LONG volatile *Addend
);

Una aplicación grande en la que solía trabajar a principios de la década de 1990 contenía manejo de excepciones basado en C usando setjmp y longjmp. La palabra clave volátil era necesaria en las variables cuyos valores debían ser preservados en el bloque de código que servía como cláusula "catch", para que esos vars no se almacenaran en registros y fueran eliminados por el longjmp.

En el Estándar C, uno de los lugares para usar volatilees con un controlador de señal. De hecho, en el Estándar C, todo lo que puede hacer con seguridad en un controlador de señal es modificar una volatile sig_atomic_tvariable o salir rápidamente. De hecho, AFAIK, es el único lugar en el Estándar C en el que volatilese requiere el uso para evitar un comportamiento indefinido.

ISO / IEC 9899: 2011 §7.14.1.1 La signalfunción

¶5 Si la señal se produce de otra manera que como resultado de llamar a la función aborto raise, el comportamiento no está definido si el controlador de señal se refiere a cualquier objeto con una duración de almacenamiento estático o de subprocesos que no sea un objeto atómico sin bloqueo que no sea mediante la asignación de un valor a un objeto declarado como volatile sig_atomic_t, o el manejador de señal llama a cualquier función en la biblioteca estándar que no sea la abortfunción, la _Exitfunción, la quick_exitfunción o la signalfunción con el primer argumento igual al número de señal correspondiente a la señal que causó la invocación del manipulador. Además, si dicha llamada a la signalfunción da como resultado un retorno SIG_ERR, el valor de errnoes indeterminado. ²⁵²⁾

²⁵²⁾ Si un controlador de señal asíncrono genera alguna señal, el comportamiento es indefinido.

Eso significa que en el Estándar C, puedes escribir:

static volatile sig_atomic_t sig_num = 0;

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

Y no mucho más.

POSIX es mucho más indulgente con respecto a lo que puede hacer en un controlador de señal, pero aún existen limitaciones (y una de las limitaciones es que la biblioteca de E / S estándar, printf()et al., No se puede usar de forma segura).

Desarrollando para un incrustado, tengo un bucle que verifica una variable que se puede cambiar en un controlador de interrupciones. Sin "volátil", el bucle se convierte en un noop, por lo que el compilador puede ver, la variable nunca cambia, por lo que optimiza la verificación.

Lo mismo se aplicaría a una variable que se puede cambiar en un subproceso diferente en un entorno más tradicional, pero a menudo hacemos llamadas de sincronización, por lo que el compilador no es tan libre con la optimización.

Lo he usado en compilaciones de depuración cuando el compilador insiste en optimizar una variable que quiero ver mientras paso por el código.

Además de usarlo según lo previsto, se utiliza volátil en la metaprogramación (plantilla). Se puede utilizar para evitar la sobrecarga accidental, ya que el atributo volátil (como const) participa en la resolución de sobrecarga.

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

Esto es legal; ambas sobrecargas son potencialmente invocables y hacen casi lo mismo. El reparto en la volatilesobrecarga es legal ya que sabemos que la barra no pasará un no volátil de Ttodos modos. Sin volatileembargo, la versión es estrictamente peor, por lo que nunca se elige en resolución de sobrecarga si no es volátilf está disponible.

Tenga en cuenta que el código nunca depende del volatileacceso a la memoria.

1. debe usarlo para implementar spinlocks, así como algunas estructuras de datos sin bloqueo (¿todas?)
2. Úselo con operaciones atómicas / instrucciones
3. una vez me ayudó a superar el error del compilador (código generado incorrectamente durante la optimización)

los volatile palabra clave está destinada a evitar que el compilador aplique optimizaciones en los objetos que pueden cambiar de formas que el compilador no puede determinar.

Los objetos declarados como volatilese omiten de la optimización porque sus valores pueden ser cambiados por código fuera del alcance del código actual en cualquier momento. El sistema siempre lee el valor actual de un volatileobjeto desde la ubicación de la memoria en lugar de mantener su valor en el registro temporal en el punto en el que se solicita, incluso si una instrucción previa solicitaba un valor del mismo objeto.

Considere los siguientes casos

1) Variables globales modificadas por una rutina de servicio de interrupción fuera del alcance.

2) Variables globales dentro de una aplicación multiproceso.

Si no usamos calificador volátil, pueden surgir los siguientes problemas

1) El código puede no funcionar como se esperaba cuando la optimización está activada.

2) El código puede no funcionar como se esperaba cuando las interrupciones están habilitadas y utilizadas.

Volátil: el mejor amigo de un programador

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

Aparte del hecho de que la palabra clave volátil se utiliza para decirle al compilador no para optimizar el acceso a alguna variable (que pueden ser modificados por un hilo o una rutina de interrupción), se puede también utilizar para eliminar algunos errores de compilación - Sí, se puede ser ---.

Por ejemplo, trabajé en una plataforma integrada donde el compilador estaba haciendo algunas suposiciones erróneas con respecto al valor de una variable. Si el código no estuviera optimizado, el programa se ejecutaría correctamente. Con las optimizaciones (que realmente eran necesarias porque era una rutina crítica), el código no funcionaría correctamente. La única solución (aunque no muy correcta) fue declarar la variable 'defectuosa' como volátil.

¿Su programa parece funcionar incluso sin volatilepalabra clave? Quizás esta sea la razón:

Como se mencionó anteriormente, la volatilepalabra clave ayuda para casos como

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

Pero parece que casi no hay efecto una vez que se llama a una función externa o no en línea. P.ej:

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

Luego con o sin volatilecasi el mismo resultado se genera.

Mientras g () pueda estar completamente en línea, el compilador puede ver todo lo que está sucediendo y, por lo tanto, puede optimizarlo. Pero cuando el programa hace una llamada a un lugar donde el compilador no puede ver lo que está sucediendo, ya no es seguro que el compilador haga suposiciones. Por lo tanto, el compilador generará código que siempre se lee directamente de la memoria.

Pero tenga cuidado con el día, cuando su función g () esté en línea (ya sea debido a cambios explícitos o debido a la inteligencia del compilador / enlazador), ¡entonces su código podría romperse si olvida la volatilepalabra clave!

Por lo tanto, recomiendo agregar la volatilepalabra clave incluso si su programa parece funcionar sin él. Hace que la intención sea más clara y robusta con respecto a los cambios futuros.

En los primeros días de C, los compiladores interpretarían todas las acciones que leen y escriben valores como operaciones de memoria, para realizarse en la misma secuencia que las lecturas y escrituras aparecieron en el código. La eficiencia podría mejorarse enormemente en muchos casos si los compiladores tuvieran cierta libertad para reordenar y consolidar operaciones, pero hubo un problema con esto. Incluso las operaciones a menudo se especificaban en un cierto orden simplemente porque era necesario especificarlas en algún orden y, por lo tanto, el programador eligió una de muchas alternativas igualmente buenas, que no siempre fue el caso. Algunas veces sería importante que ciertas operaciones ocurran en una secuencia particular.

Exactamente qué detalles de la secuencia son importantes variará según la plataforma de destino y el campo de aplicación. En lugar de proporcionar un control particularmente detallado, el Estándar optó por un modelo simple: si una secuencia de accesos se realiza con valores que no están calificados volatile, un compilador puede reordenarlos y consolidarlos como mejor le parezca. Si una acción se realiza con un valor volatilel calificado, una implementación de calidad debe ofrecer las garantías de pedido adicionales que pueda requerir el código dirigido a su plataforma y campo de aplicación previstos, sin tener que requerir el uso de una sintaxis no estándar.

Desafortunadamente, en lugar de identificar qué garantías necesitarían los programadores, muchos compiladores han optado por ofrecer las mínimas garantías exigidas por el Estándar. Esto hace volatilemucho menos útil de lo que debería ser. En gcc o clang, por ejemplo, un programador que necesita implementar un "mutex de traspaso" básico [uno donde una tarea que ha adquirido y liberado un mutex no volverá a hacerlo hasta que la otra tarea lo haya hecho] debe hacer uno de cuatro cosas:

1. Ponga la adquisición y el lanzamiento del mutex en una función que el compilador no puede en línea y a la que no puede aplicar la optimización de todo el programa.

2. Califique todos los objetos guardados por el mutex como volatilealgo que no debería ser necesario si todos los accesos ocurren después de adquirir el mutex y antes de liberarlo.

3. Use el nivel de optimización 0 para forzar al compilador a generar código como si todos los objetos que no registerestán calificados lo estén volatile.

4. Use las directivas específicas de gcc.

Por el contrario, cuando se utiliza un compilador de mayor calidad que es más adecuado para la programación de sistemas, como icc, uno tendría otra opción:

5. Asegúrese de que se volatilerealice una escritura calificada en todos los lugares donde se necesite una adquisición o liberación.

La adquisición de un "mutex de traspaso básico" requiere una volatilelectura (para ver si está lista), y no debería requerir una volatileescritura también (el otro lado no intentará volver a adquirirlo hasta que se devuelva) pero tiene que Realizar una volatileescritura sin sentido es aún mejor que cualquiera de las opciones disponibles bajo gcc o clang.

Un uso que debo recordarle es que, en la función de controlador de señal, si desea acceder / modificar una variable global (por ejemplo, marcarla como exit = true), debe declarar esa variable como 'volátil'.

Todas las respuestas son excelentes. Pero además de eso, me gustaría compartir un ejemplo.

A continuación se muestra un pequeño programa 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;
}

Ahora, generemos el ensamblaje del código anterior (y pegaré solo las partes del ensamblaje que sean relevantes aquí):

El comando para generar ensamblaje:

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

Y la asamblea:

main:
.LFB1594:
    subq    $40, %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    $8, x(%rip)  #, x
 # assembly.cpp:10:         printf("x is 8\n");
    call    _ZL6printfPKcz.constprop.0   #
 # assembly.cpp:18: }
    xorl    %eax, %eax   #
    movl    $5, x(%rip)  #, x
    addq    $40, %rsp    #,
    ret 
    .seh_endproc
    .p2align 4,,15
    .def    _GLOBAL__sub_I_x;   .scl    3;  .type   32; .endef
    .seh_proc   _GLOBAL__sub_I_x

Puede ver en el ensamblado que el código de ensamblado no se generó sprintfporque el compilador asumió que xeso no cambiará fuera del programa. Y lo mismo ocurre con el whilebucle.whileEl bucle se eliminó por completo debido a la optimización porque el compilador lo vio como un código inútil y, por lo tanto, lo asignó directamente 5a x(ver movl $5, x(%rip)).

El problema ocurre cuando ¿qué pasa si un proceso / hardware externo cambiaría el valor de xalgún punto intermedio?x = 8; y if(x == 8). Es de esperar que el elsebloque funcione, pero desafortunadamente el compilador ha recortado esa parte.

Ahora, para resolver esto, en el assembly.cpp, cambiemos int x;avolatile int x; y rápidamente ver el código ensamblador generado:

main:
.LFB1594:
    subq    $104, %rsp   #,
    .seh_stackalloc 104
    .seh_endprologue
 # assembly.cpp:5: int main(){
    call    __main   #
 # assembly.cpp:7:     x = 8;
    movl    $8, x(%rip)  #, x
 # assembly.cpp:9:     if(x == 8)
    movl    x(%rip), %eax    # x, x.1_1
 # assembly.cpp:9:     if(x == 8)
    cmpl    $8, %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    $1000, x(%rip)   #, x
 # assembly.cpp:15:     while(x > 5)
    movl    x(%rip), %eax    # x, x.3_15
    cmpl    $5, %eax     #, x.3_15
    jle .L8  #,
    .p2align 4,,10
.L9:
 # assembly.cpp:16:         x--;
    movl    x(%rip), %eax    # x, x.4_3
    subl    $1, %eax     #, _4
    movl    %eax, x(%rip)    # _4, x
 # assembly.cpp:15:     while(x > 5)
    movl    x(%rip), %eax    # x, x.3_2
    cmpl    $5, %eax     #, x.3_2
    jg  .L9  #,
.L8:
 # assembly.cpp:18: }
    xorl    %eax, %eax   #
    addq    $104, %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

Aquí se puede ver que los códigos de montaje para sprintf, printfy whilese generaron bucle. La ventaja es que si xalgún programa externo o hardware cambia la variable sprintf, se ejecutará parte del código. Y de forma similar, el whilebucle se puede usar para ocupados esperando ahora.

Otras respuestas ya mencionan evitar algunas optimizaciones para:

• usar registros mapeados en memoria (o "MMIO")
• escribir controladores de dispositivo
• permitir una depuración más fácil de programas
• hacer cálculos de coma flotante más deterministas

La volátil es esencial siempre que necesite que un valor parezca provenir del exterior y sea impredecible y evite las optimizaciones del compilador en función de un valor conocido, y cuando un resultado no se usa realmente pero necesita que se calcule, o se usa, pero desea calcularlo varias veces para un punto de referencia, y necesita que los cálculos comiencen y terminen en puntos precisos.

Una lectura volátil es como una operación de entrada (como scanfo un uso de cin): el valor parece provenir del exterior del programa, por lo que cualquier cálculo que dependa del valor debe comenzar después .

Una escritura volátil es como una operación de salida (como printfo un uso de cout): el valor parece comunicarse fuera del programa, por lo que si el valor depende de un cálculo, debe terminarse antes .

Por lo tanto, se puede usar un par de lectura / escritura volátil para domar los puntos de referencia y hacer que la medición del tiempo sea significativa .

Sin volátil, el compilador podría iniciar su cálculo antes, ya que nada impediría la reordenación de los cálculos con funciones como la medición del tiempo .