.NET Enhebrado: es necesario un bloqueo para las asignaciones

Question

Tengo un código de varios subprocesos. Me gustaría aumentar el rendimiento un poco, así que me pregunto si puedo deshacerme de un bloqueo.

Tengo un miembro de campo:

private IList<ServerStatus> status; 

Se actualiza en un hilo de este modo:

status = GetUpdatedStatus(); 

y se usa en otro hilo de esta manera:

var currentStatus = status; 

Entonces, la pregunta es, ¿puede lo anterior producir algún problema sin bloqueos alrededor de las dos declaraciones de asignación?

supongo que el único escenario que puedo ver es currentStatus siendo nula, pero entonces, yo era de esperar una asignación a ser algo seguro para subprocesos (ya sea que se ha cambiado la referencia o no)

Answer 1

Tiene usted razón. Verás la tarea o no la verás. Las asignaciones (y lecturas) de referencias son siempre "atómicas" (al final es porque en máquinas de 32 bits las referencias son de 32 bits, por lo que se puede hacer atómicamente, y en máquinas de 64 bits (ejecutando una aplicación de 64 bits) las referencias son 64 bits; por lo que se puede hacer de forma atómica. La única excepción está intentando escribir/leer unas largas (64 bits) en una máquina de 32 bits. Hay que tendría que utilizar Interlocked.Read/Interlocked.Exchange)

Normalmente debería declarar estado como volatile, por lo que cada subproceso solo ve la última versión. Deberías leer esto: http://www.albahari.com/threading/ ¡es muy, muy bueno!

Si usted no confía en mí, lea la sección Do We Really Need Locks and Barriers? aquí http://www.albahari.com/threading/part4.aspx

Ah ... me olvidaba ... el mundo los odia, así que hay una pequeña cosa que saber de volátiles: a veces no funciona :-) :-) Lea, en la misma página del otro ejemplo, la sección The volatile keyword, la parte BAJO el cuadro rojo. Notice that applying volatile doesn’t prevent a write followed by a read from being swapped, and this can create brainteasers. Al final, la única forma de estar seguro es usar Interlocked.Exchange para escribir y Interlocked.CompareExchange para leer algo O proteger las secciones de lectura y escritura con sincronización (como lock) O llenar su programa con Thread.MemoryBarrier (pero no lo intente) , fallarás, y ni siquiera sabrás por qué). Se le garantiza que todas las lecturas y escrituras hechas en el bloqueo se realizarán en el bloqueo, no antes ni después.

Answer 2

escrituras de referencia están garantizados atómica, por lo que sólo hay realmente dos cosas a comprobar:

uso

• en un bucle estrecho - podría necesitar agregar volatile si es necesario notar el cambio
• actualizaciones dobles; si está (por ejemplo) haciendo add/remove mediante swap de referencia, debe usar Interlocked.CompareExchange para asegurarse de no perder datos; mantener a volver a aplicar los cambios hasta que gane el canje

es decir

object snapshot, newValue; 
do 
{ 
    snapshot = field; 

    // do something based on that; create a clone 
    // with more/less data for example 
    newValue = ...; 
} while (!ReferenceEquals(
    Interlocked.CompareExchange(ref field, newValue, snapshot), snapshot));