Bloqueando una sola variable bool cuando multihilo?

Question

recientemente he visto este código en un sitio web, y mi pregunta es la siguiente:

 private bool mbTestFinished = false; 

     private bool IsFinished() 
     { 
      lock(mLock) 
      { 
       return mbTestFinished; 
      } 
     } 

     internal void SetFinished() 
     { 
      lock(mLock) 
      { 
       mbTestFinished = true; 
      } 
     } 

En un entorno multi-hilo, que es realmente necesario para bloquear el acceso al mbTestFinished?

Answer 1

Sí, es necesario. El entorno .Net utiliza algunas optimizaciones y, a veces, si se accede a una ubicación de memoria con frecuencia, los datos se transfieren a los registros de la CPU. Entonces, en este caso, si mbTestFinished está en un registro de CPU, entonces un hilo que lo lea puede tener un valor incorrecto. Por lo tanto, el uso de la clave volátil garantiza que todos los accesos a esta variable se realicen en la ubicación de la memoria, no en los registros. Por otro lado, no tengo idea de la frecuencia de esta ocurrencia. Esto puede ocurrir a una frecuencia muy baja.

Answer 2

En mi opinión, no, la cerradura está de más aquí, por dos razones:

1. variables booleanas no pueden causar lagrimeo asignación como long por ejemplo, por lo tanto, el bloqueo no es necesario.
2. Para resolver el problema de visibilidad volatile es suficiente. Es cierto que el lock introduce una valla implícita, pero como el lock no es necesario para la atomicidad, es suficiente con volatile.

Answer 3

Si mlock es SOLO para la variable mbTestFinished, entonces es un poco de una exageración. En su lugar, puede usar volátil o Interbloqueado, porque ambos son Construcciones en modo de usuario para la sincronización de subprocesos. bloquear (o Monitor de) es un híbrido Construct, en el sentido de que está bien optimizado para evitar que transitan desde/hasta el modo de núcleo siempre que sea posible. El libro "CLR a través de C#" tiene una discusión en profundidad de estos conceptos.