¿Es necesario un bloqueo en esta situación?

Question

¿Es necesario proteger el acceso a una sola variable de un tipo de referencia en una aplicación multiproceso? Actualmente bloqueo esa variable de esta manera:

private readonly object _lock = new object(); 
private MyType _value; 
public MyType Value 
{ 
    get { lock (_lock) return _value; } 
    set { lock (_lock) _value = value; } 
} 

Pero me pregunto si esto es realmente necesario? ¿La asignación de un valor a un campo no es atómica? ¿Algo puede salir mal si no bloqueo este caso?

P.S .: MyType es una clase inmutable: todos los campos están establecidos en el constructor y no cambian. Para cambiar algo, se crea una nueva instancia y se asigna a la variable anterior.

Answer 1

Ser atómico es raramente suficiente.

Por lo general, quiero obtener el último valor de una variable, en lugar de verla como obsoleta, por lo que se requiere algún tipo de barrera de memoria, tanto para leer como para escribir. Un bloqueo es una forma simple de hacer esto bien, a costa de perder potencialmente algún rendimiento debido a la disputa.

I usó para creer que hacer la variable volátil sería suficiente en esta situación. Ya no estoy convencido de que este sea el caso. Básicamente, ahora trato de evitar escribir código sin candado cuando se trata de datos compartidos, a menos que pueda usar bloques escritos por personas que realmente entienden estas cosas (por ejemplo, Joe Duffy).

Answer 2

todo depende de si se accederá a la propiedad por varios hilos. y se dice que alguna variable es una operación atómica, en este caso de operación atómica, no es necesario usar el bloqueo. lo siento por un inglés pobre.

en tu caso, inmutable, creo que no es necesario el bloqueo.

Answer 3

Existe la palabra clave volatile para esto. Si es seguro o no depende del escenario. Pero el compilador puede hacer funny stuff, como reorganizar el orden de operación. Entonces, incluso leer/escribir en un campo puede ser inseguro.

Answer 4

Puede ser un problema. No se trata solo de la tarea en sí misma. Debido al almacenamiento en caché, los subprocesos simultáneos pueden ver una versión anterior del objeto si no se bloquea. Entonces, si un bloqueo es necesario dependerá exactamente de cómo lo use, y usted no lo muestra.

Aquí hay un free, sample chapter of "Concurrent Programming in Windows" que explica este problema en detalle.