Bloqueo en C#

Question

Todavía estoy un poco confuso y cuándo ajustar un bloqueo alrededor de algún código. Mi regla general es ajustar una operación en un bloqueo cuando lee o escribe en una variable estática. Pero cuando una variable estática SOLAMENTE se lee (por ejemplo, es un archivo de solo lectura que se configura durante la inicialización del tipo), acceder a ella no tiene que estar envuelto en una declaración de bloqueo, ¿verdad? Hace poco vi un código que parecía el siguiente ejemplo, y me hizo pensar que puede haber algunas lagunas en mi conocimiento multihilo:

class Foo 
{ 
    private static readonly string bar = "O_o"; 

    private bool TrySomething() 
    { 
     string bar; 

     lock(Foo.objectToLockOn) 
     { 
      bar = Foo.bar;   
     }  

     // Do something with bar 
    } 
} 

Eso simplemente no tiene sentido para mí - ¿Por qué habría de concurrencia problemas con LEER un registro?

Además, este ejemplo plantea otra pregunta. ¿Es uno de estos mejor que el otro? (Por ejemplo, Ejemplo de dos mantiene el bloqueo por menos tiempo?) Supongo que podría desmontar el MSIL ...

class Foo 
{ 
    private static string joke = "yo momma"; 

    private string GetJoke() 
    { 
     lock(Foo.objectToLockOn) 
     { 
      return Foo.joke; 
     } 
    } 
} 

vs

class Foo 
{ 
    private static string joke = "yo momma"; 

     private string GetJoke() 
     { 
      string joke; 

      lock(Foo.objectToLockOn) 
      { 
       joke = Foo.joke; 
      } 

      return joke; 
     } 
} 

Answer 1

Dado que ninguno de los códigos que ha escrito modifica el campo estático después de la inicialización, no hay necesidad de ningún bloqueo. El solo reemplazo de la cadena con un nuevo valor tampoco necesitará sincronización, a menos que el nuevo valor dependa de los resultados de una lectura del valor anterior.

Los campos estáticos no son los únicos que necesitan sincronización, cualquier referencia compartida que pueda modificarse es vulnerable a problemas de sincronización.

class Foo 
{ 
    private int count = 0; 
    public void TrySomething()  
    { 
     count++; 
    } 
} 

Puede suponer que dos subprocesos que ejecutan el método TrySomething estarían bien. Pero no lo es.

1. El subproceso A lee el valor de conteo (0) en un registro para que pueda ser incrementado.
2. Cambio de contexto! El programador de subprocesos decide que el subproceso A tuvo suficiente tiempo de ejecución. El siguiente en la línea es el Hilo B.
3. El Hilo B lee el valor del conteo (0) en un registro.
4. El subproceso B incrementa el registro.
5. El hilo B guarda el resultado (1) para contar.
6. Cambio de contexto a A.
7. El subproceso A vuelve a cargar el registro con el valor del recuento (0) guardado en su pila.
8. El subproceso A incrementa el registro.
9. El subproceso A guarda el resultado (1) para contar.

Así, a pesar de que hemos llamado recuento ++ dos veces, el valor de recuento se acaba de ir de 0 a 1. Permite que el código sea seguro para subprocesos:

class Foo 
{ 
    private int count = 0; 
    private readonly object sync = new object(); 
    public void TrySomething()  
    { 
     lock(sync) 
      count++; 
    } 
} 

Ahora, cuando subproceso A se interrumpe Tema B no se puede meter con la cuenta porque golpeará la instrucción de bloqueo y luego bloqueará hasta que el hilo A haya liberado la sincronización.

Por cierto, no es una forma alternativa de hacer incrementar Int32s y Int64s flujos seguros:

class Foo 
{ 
    private int count = 0; 
    public void TrySomething()  
    { 
     System.Threading.Interlocked.Increment(ref count); 
    } 
} 

En cuanto a la segunda parte de su pregunta, creo que me gustaría ir con el que sea más fácil de leer , cualquier diferencia de rendimiento será insignificante. optimización temprana es la raíz de todo mal, etc.

Why threading is hard

Answer 2

Si acaba de escribir un valor a un puntero, no es necesario bloquear, ya que esa acción es atómica. En general, debe bloquear cada vez que necesite realizar una transacción que implique al menos dos acciones atómicas (lecturas o escrituras) que dependan de que el estado no cambie entre el principio y el final.

Dicho esto: vengo de Java, donde todas las lecturas y escrituras de variables son acciones atómicas. Otras respuestas aquí sugieren que .NET es diferente.

Answer 3

¿Dirty reads?

Answer 4

Leer o escribir un campo de 32 bits o más pequeño es una operación atómica en C#. No hay necesidad de bloquear el código que presentaste, por lo que puedo ver.

Answer 5

En mi opinión, debe esforzarse mucho para no colocar las variables estáticas en una posición donde se necesiten leer/escribir desde diferentes subprocesos. En este caso, son esencialmente variables globales para todos, y los globales son casi siempre una mala cosa.

Dicho esto, si lo hace poner una variable estática en una posición tal, es posible que desee para bloquear durante una lectura, por si acaso - recuerde, otro hilo puede haber abalanzaron y cambiado el valor durante la lectura , y si lo hace, puede terminar con datos corruptos. Las lecturas no son necesariamente operaciones atómicas a menos que usted se asegure de que estén bloqueadas. Lo mismo con las escrituras: tampoco son siempre operaciones atómicas.

Editar: Como señaló Mark, para ciertas primitivas en C# las lecturas son siempre atómicas. Pero ten cuidado con otros tipos de datos.

Answer 6

En cuanto a su pregunta "cuál es mejor", son las mismas ya que el alcance de la función no se utiliza para nada más.

Answer 7

Me parece que el bloqueo no es necesario en su primer caso. Se garantiza que el uso del inicializador estático para inicializar la barra sea seguro para subprocesos. Como solo lee el valor, no es necesario bloquearlo. Si el valor nunca va a cambiar, nunca habrá ninguna contención, ¿por qué bloquearlo?