¿Cuál es el costo de la palabra clave volátil en un sistema multiprocesador?

Question

nos encontramos con problemas de rendimiento, y un posible culpable es el uso centralizado de un singleton volátil. el código específico es de la forma

class foo { 
    static volatile instance; 
    static object l = new object(); 

    public static foo Instance { 
    if (instance == null) 
     lock(l) { 
     if (instance == null) 
      instance = new foo(); 
     } 

    return foo(); 
    } 
} 

esto se ejecuta en un cuadro de 8 vías, y estamos viendo el cambio de contexto por una suma de 500.000 por segundo. los recursos típicos del sistema son correctos: 25% de CPU, 25% de memoria de uso, IO bajo, sin paginación, etc.

¿El uso de un campo volátil induce una barrera de memoria o cualquier tipo de recarga de caché de la CPU? ¿o simplemente va detrás de la memoria principal todo el tiempo, solo para ese campo?

Answer 1

lock induce una barrera de memoria, por lo que si siempre está accediendo a instancia en un bloqueo no necesita el volátil.

Según this site:

El C# implementos de palabras clave volátiles adquieren y liberan la semántica, lo que implica una barrera de memoria de lectura de leer y una barrera de memoria de escritura en escritura.

Answer 2

Lamentablemente, el singleton tiene una mala reputación para casi todo :)

Ésta no es mi campo de especialización, pero por lo que sé no es nada especial sobre volátil que no sea el compilador/run -time NO reordenar lecturas/escrituras (a la variable) para fines de optimización.

Editar: Estoy corregido. No solo los volátiles introducen barreras de memoria, sino que lo que sucede (y de paso, el rendimiento) depende en gran medida de la CPU particular involucrada. Consulte http://dotnetframeworkplanet.blogspot.com/2008/11/volatile-field-and-memory-barrier-look.html

Es por esto que todavía necesita el candado.

Preguntas que puede/no puede ya han sido contestadas:

1. ¿Cuál es su instancia singleton realmente hacer? Tal vez el código de instancia debe ser refactorizado ...
2. ¿Cuál es el conteo de subprocesos del proceso de ejecución? Una caja de 8 vías no lo ayudará si tiene un número de hilos anormalmente alto.
3. Si es más alto de lo esperado, ¿por qué?
4. ¿Qué más está funcionando en el sistema?
5. ¿El problema de rendimiento es constante?

Answer 3

En su ejemplo aquí, volátil no debería ser objeto de ninguna "ralentización". Sin embargo, el bloqueo() puede implicar viajes largos al kernel, especialmente si hay mucha disputa por el bloqueo.

En realidad no hay necesidad de bloquear el singleton en este caso, sólo podría hacerlo

class Foo { 
    static Foo instance = new Foo(); 
    public static Foo FooInstance() { 
    return instance ; 
    } 
} 

Por supuesto, si 'ejemplo' se utiliza en una gran cantidad de diferentes hilos, usted todavía tiene que bloquear() cualquier cosa que altere ese Foo, a menos que todos los métodos/propiedades de Foo sean de solo lectura. p.

class Foo { 
     static Foo instance = new Foo(); 
     object l = new object(); 
     int doesntChange = 42; 
     int canChange = 123; 
     public static Foo FooInstance() { 
     return instance ; 
     } 
     public void Update(int newVal) { 
     lock(l) { // you'll get a lot of trouble without this lock if several threads accesses the same FOO. Atleast if they later on read that variable 
      canChange = newVal; 
     } 

     public int GetFixedVal() { 
     return doesntChange; //no need for a lock. the doesntChange is effectivly read only 
     } 
    } 

Answer 4

En realidad no hay necesidad de que el uso de la volátil para un producto único, ya que se está configurando es exactamente una vez - y bloquear el código de los conjuntos de TI. Ver Jon Skeet's article on singletons para más información.

Answer 5

Una cosa que no hace volátil es provocar un cambio de contexto. Si está viendo 500,000 cambios de contexto por segundo, significa que sus hilos están bloqueados en algo y volátil es no el culpable.

Answer 6

La respuesta corta es Sí, crea una barrera de memoria (vacía todo y va a la memoria principal, no solo a esa única variable), pero No no será la causa del cambio de contexto.

Además, como han mencionado otros, no creo que la volatilidad sea necesaria aquí.