La asignación de referencia es atómica, entonces, ¿por qué se necesita Interlocked.Exchange (ref Object, Object)?

En mi servicio web asmx multiproceso, tenía un campo de clase _allData de mi propio tipo SystemData que consta de pocos List<T>y está Dictionary<T>marcado como volatile. Los datos del sistema ( _allData) se actualizan de vez en cuando y lo hago creando otro objeto llamado newDatay lleno sus estructuras de datos con nuevos datos. Cuando termine, solo asigno

private static volatile SystemData _allData

public static bool LoadAllSystemData()
{
    SystemData newData = new SystemData();
    /* fill newData with up-to-date data*/
     ...
    _allData = newData.
} 

Esto debería funcionar ya que la asignación es atómica y los subprocesos que tienen la referencia a datos antiguos siguen usándola y el resto tiene los nuevos datos del sistema justo después de la asignación. Sin embargo, mi colega dijo que en lugar de usar una volatilepalabra clave y una asignación simple, debería usar InterLocked.Exchangeporque dijo que en algunas plataformas no se garantiza que la asignación de referencia sea atómica. Además: cuando declaro the _allDatacampo como volatileel

Interlocked.Exchange<SystemData>(ref _allData, newData); 

produce una advertencia "una referencia a un campo volátil no se tratará como volátil" ¿Qué debo pensar al respecto?

Aquí hay numerosas preguntas. Considerándolos uno a la vez:

La asignación de referencia es atómica, entonces, ¿por qué se necesita Interlocked.Exchange (ref Object, Object)?

La asignación de referencia es atómica. Interlocked.Exchange no solo hace referencia a la asignación. Hace una lectura del valor actual de una variable, oculta el valor anterior y asigna el nuevo valor a la variable, todo como una operación atómica.

mi colega dijo que en algunas plataformas no se garantiza que la asignación de referencias sea atómica. ¿Tenía razón mi colega?

No. Se garantiza que la asignación de referencia será atómica en todas las plataformas .NET.

Mi colega está razonando desde premisas falsas. ¿Significa eso que sus conclusiones son incorrectas?

No necesariamente. Su colega podría estar dándole buenos consejos por malas razones. Quizás haya alguna otra razón por la que debería utilizar Interlocked.Exchange. La programación sin candados es increíblemente difícil y en el momento en que se aparta de las prácticas bien establecidas defendidas por los expertos en el campo, se pierde en la maleza y se arriesga a las peores condiciones de carrera. No soy un experto en este campo ni un experto en su código, por lo que no puedo emitir un juicio de una forma u otra.

produce una advertencia "una referencia a un campo volátil no se tratará como volátil" ¿Qué debo pensar al respecto?

Debe comprender por qué esto es un problema en general. Eso conducirá a comprender por qué la advertencia no es importante en este caso particular.

La razón por la que el compilador da esta advertencia es porque marcar un campo como volátil significa "este campo se actualizará en varios subprocesos; no genere ningún código que almacene en caché los valores de este campo y asegúrese de que las lecturas o escrituras de este campo no se "mueve hacia adelante y hacia atrás en el tiempo" a través de inconsistencias de caché del procesador ".

(Supongo que ya comprende todo eso. Si no tiene una comprensión detallada del significado de volátil y cómo afecta la semántica de la caché del procesador, entonces no comprende cómo funciona y no debería usar volátil. Programas sin bloqueo son muy difíciles de hacer bien; asegúrese de que su programa sea correcto porque comprende cómo funciona, no por accidente).

Ahora suponga que crea una variable que es un alias de un campo volátil pasando una referencia a ese campo. Dentro del método llamado, el compilador no tiene ningún motivo para saber que la referencia debe tener semántica volátil. El compilador generará alegremente código para el método que no implementa las reglas para los campos volátiles, pero la variable es un campo volátil. Eso puede arruinar completamente su lógica libre de bloqueos; siempre se asume que siempre se accede a un campo volátil con semántica volátil. No tiene sentido tratarlo como volátil algunas veces y otras no; tiene que ser siempre coherente, de lo contrario no puede garantizar la coherencia en otros accesos.

Por lo tanto, el compilador le advierte cuando hace esto, porque probablemente va a estropear por completo su lógica sin bloqueos cuidadosamente desarrollada.

Por supuesto, Interlocked.Exchange está escrito para esperar un campo volátil y hacer lo correcto. Por tanto, la advertencia es engañosa. Lo lamento mucho; lo que deberíamos haber hecho es implementar algún mecanismo mediante el cual un autor de un método como Interlocked.Exchange podría poner un atributo en el método diciendo "este método que toma una referencia aplica la semántica volátil en la variable, así que suprime la advertencia". Quizás en una versión futura del compilador lo hagamos.

O su colega se equivoca o sabe algo que la especificación del lenguaje C # no sabe.

5.5 Atomicidad de referencias variables :

"Las lecturas y escrituras de los siguientes tipos de datos son atómicas: bool, char, byte, sbyte, short, ushort, uint, int, float y tipos de referencia".

Por lo tanto, puede escribir en la referencia volátil sin riesgo de obtener un valor dañado.

Por supuesto, debe tener cuidado con la forma en que decide qué hilo debe buscar los nuevos datos, para minimizar el riesgo de que más de un hilo a la vez lo haga.

Interbloqueado Intercambio <T>

Establece una variable del tipo T especificado en un valor especificado y devuelve el valor original, como una operación atómica.

Cambia y devuelve el valor original, es inútil porque solo quieres cambiarlo y, como dijo Guffa, ya es atómico.

A menos que un generador de perfiles haya demostrado que es un cuello de botella en su aplicación, debe considerar deshacer los bloqueos, es más fácil de entender y demostrar que su código es correcto.

Iterlocked.Exchange() no es solo atómico, también se ocupa de la visibilidad de la memoria:

Las siguientes funciones de sincronización utilizan las barreras adecuadas para garantizar el orden de la memoria:

Funciones que entran o salen de secciones críticas

Funciones que señalan objetos de sincronización

Funciones de espera

Funciones enclavadas

Problemas de sincronización y multiprocesador

Esto significa que además de la atomicidad asegura que:

• Para el hilo que lo llama:
  • No se realiza ningún reordenamiento de las instrucciones (por parte del compilador, el tiempo de ejecución o el hardware).
• Para todos los hilos:
  • Ninguna lectura en la memoria que ocurra antes de esta instrucción verá el cambio que esta instrucción realizó.
  • Todas las lecturas posteriores a esta instrucción verán el cambio realizado por esta instrucción.
  • Todas las escrituras en la memoria después de esta instrucción sucederán después de que este cambio de instrucción haya llegado a la memoria principal (al vaciar este cambio de instrucción a la memoria principal cuando esté hecho y no dejar que el hardware lo limpie por sí mismo).