c++ - Consecuencias en el rendimiento de las funciones de los miembros volátiles.

multithreading volatile

Question

Encontré un artículo de 2001 sobre Dr Dobbs: volatile - El mejor amigo del programador multiproceso . Siempre me ha parecido "inestable" algo inútil, al menos como calificador de variables, ya que el acceso a las variables compartidas entre hilos siempre pasa por algún tipo de capa de biblioteca de todos modos.

No obstante, marcar las instancias y los métodos de clase como "volátiles" para indicar el grado de seguridad de los hilos como se presenta en el artículo parece muy convincente.

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

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

Y luego, instancias de la clase, como esta:

// 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 se implementen métodos como "Method () volatile":

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

Obviamente, los punteros inteligentes pueden automatizar el proceso atómico de bloqueo y conversión a no volátil; el punto es que el calificador volátil se puede usar, en su uso previsto, para marcar los miembros de la clase y las instancias para indicar cómo van. para ser utilizado desde múltiples subprocesos y, por lo tanto, hacer que el compilador le diga al desarrollador cuándo se están invocando métodos de un solo hilo (no volátiles) en un objeto volátil, o incluso que elija la versión segura para subprocesos.

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 suponer 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 arrastre de rendimiento en cualquier función de miembro calificado volátil si es así.

Answer 1

• No, las variables locales no se asumirán como volátiles en un método volátil, casi de la misma manera que las variables locales no se suponen constantes en un método const.
• Todos los miembros de la clase serán tratados como volátiles dentro del método volátil, casi de la misma manera que todos los miembros no mutables se tratan const en un método const. No hay equivalente de mutable para volátil.
• this no será un puntero volátil, por lo que acceder a él no lo cargará desde la memoria cada vez. Sin embargo, this será un indicador de volatilidad, lo que significa que *this se trata como volátil