Consecuencia de rendimiento de las funciones de miembros volátiles

Question

Encontré un artículo de 2001 sobre el Dr. Dobbs: volatile - Multithreaded Programmer's Best Friend. Siempre he considerado que "volátil" es algo inútil, al menos como un calificador de variables, ya que el acceso a las variables compartidas entre hilos siempre pasa por algún tipo de capa de biblioteca.

No obstante, marcar instancias de clase y métodos, como 'volátil' para indicar su grado de seguridad de subprocesos como se presenta en el artículo parece muy convincente.

Para resumir el artículo rápidamente, la idea central es podría declarar una clase como esta:

struct SomeObject { 
    void SingleThreadedMethod(); 
    void Method(); 
    void Method() volatile; 
}; 

Y luego, las instancias de la clase, así:

// An object that will only be accessed from a single thread. 
SomeObject singleThreaded; 
// An objecect that will be accessed from multiple threads. 
volatile SomeObject sharedObject; 

sharedObject.SingleThreadedMethod(); //this will be an compile error 
sharedObject.Method(); // will call the volatile overload of Method 
singleThreaded.Method(); // would call the non volatile overload of Method. 

La idea es que métodos como "Método() volátil" se implementarían:

void SomeObject::Method() volatile { 
    enter_critical_section(); 
    const_cast<Method*>(this)->Method(); 
    leave_critical_Section(); 
} 

Obviamente punteros inteligentes puede automatizar el proceso atomic-lock-and-cast-to-non-volátil - el punto es que el calificador volátil se puede usar, en su uso previsto, para marcar a los miembros de la clase y las instancias para indicar cómo se van a usar desde varios hilos y, por lo tanto, hacer que el compilador le informe al desarrollador cuándo se están llamando a los métodos de un único subproceso (no volátil) en un objeto volátil, o incluso para elegir la versión de subprocesos automáticamente.

Mi pregunta sobre este enfoque es: ¿Cuáles son las implicaciones de rendimiento de los métodos calificados 'volátiles'? ¿Se obliga al compilador a asumir que todas las variables a las que se accede en una función volátil deben tratarse como volátiles y, por lo tanto, deben excluirse de las oportunidades de optimización? ¿Se excluirán las variables locales de la optimización? Eso podría ser un gran lastre para el rendimiento en cualquier función volátil de miembro calificado si es así.

Answer 1

• No, las variables locales no se asumirán como volátiles en un método volátil, más o menos de la misma manera que las variables locales no se supone const en un método const.
• Todos los miembros de la clase se tratarán como volátiles dentro del método volátil, más o menos de la misma manera que todos los miembros no mutables se tratan const en un método const. No hay un equivalente de mutable para volátil.
• this no será un puntero volátil, por lo que acceder a él no lo cargará de memoria en todo momento. Sin embargo this habrá un puntero a volátil, lo que significa que *this se trata tan volátil