¿Debo bloquear o marcar como volátil cuando accedo a un indicador booleano simple en C#?

Question

Digamos que tiene una operación simple que se ejecuta en una cadena de fondo. Desea proporcionar una forma de cancelar esta operación para que cree un indicador booleano que establezca como verdadero desde el controlador de evento click de un botón cancelar.

private bool _cancelled; 

private void CancelButton_Click(Object sender ClickEventArgs e) 
{ 
    _cancelled = true; 
} 

Ahora está configurando el indicador de cancelación del hilo de la GUI, pero lo está leyendo desde el hilo de fondo. ¿Necesita bloquear antes de acceder al bool?

se necesita para hacer esto (y, obviamente, bloquear en el botón de controlador de eventos click también):

while(operationNotComplete) 
{ 
    // Do complex operation 

    lock(_lockObject) 
    { 
     if(_cancelled) 
     { 
      break; 
     } 
    } 
} 

O es aceptable para hacer esto (sin bloqueo):

while(!_cancelled & operationNotComplete) 
{ 
    // Do complex operation 
} 

O qué tal marcar la variable cancelada como volátil. ¿Es eso necesario?

[Sé que existe la clase BackgroundWorker con su método incorporado Incorporated CancelAsync(), pero me interesa la semántica y el uso de acceso variable con bloqueo y subprocesos aquí, no la implementación específica, el código es solo un ejemplo. ]

Parece que hay dos teorías.

1) Debido a que es un tipo simple incorporado (y el acceso a tipos incorporados es atómico en .net) y porque solo estamos escribiendo en un solo lugar y solo leyendo en el hilo de fondo no hay necesidad de bloquear o marca como volátil.
2) Debe marcarlo como volátil porque si no lo hace, el compilador puede optimizar la lectura en el ciclo while porque no cree que sea capaz de modificar el valor.

¿Cuál es la técnica correcta? (¿Y por qué?)

[Editar: Parece que hay dos escuelas de pensamiento claramente definidas y opuestas sobre esto. Estoy buscando una respuesta definitiva sobre esto así que, si es posible, publique sus razones y cite sus fuentes junto con su respuesta.]

Answer 1

En primer lugar, roscado es complicado ;-P

Sí, a pesar de todos los rumores en sentido contrario, se requiere paraya sea uso lockovolatile (pero no ambos) al acceder a un bool de múltiples hilos.

Para tipos simples y acceso tales como una bandera de salida (bool), entonces es suficiente volatile - esto asegura que las discusiones no conservan el valor en sus registros (es decir: uno de los hilos nunca ve las actualizaciones).

Para valores más grandes (donde la atomicidad es un problema), o en la que desea sincronizar una secuencia de operaciones (siendo un ejemplo típico "si no existe y añadir" el acceso diccionario), un lock es más versátil. Esto actúa como una barrera de memoria, por lo que aún le da la seguridad del hilo, pero proporciona otras funciones como pulso/espera. Tenga en cuenta que no debe usar un lock en un valor-tipo o un string; ni Type o this; la mejor opción es tener su propio objeto de bloqueo como campo (readonly object syncLock = new object();) y bloquearlo.

Para ver un ejemplo de lo mal que se rompe (es decir, bucle siempre) si no se sincroniza - see here.

Para abarcar múltiples programas, una primitiva del sistema operativo como Mutex o *ResetEvent también puede ser útil, pero esto es exagerado para un solo exe.

Answer 2

_cancelled debe ser volatile. (si no elige bloquear)

Si un hilo cambia el valor de _cancelled, es posible que otros hilos no vean el resultado actualizado.

Además, creo que las operaciones de lectura/escritura de _cancelled son atómica:

Sección 12.6.6 de los estados de especificaciones de la CLI: "Un CLI conforme deberá garantizar que de lectura y escritura a correctamente ubicaciones de memoria alineadas no más grandes que el tamaño de palabra nativo es atómico cuando todos los accesos de escritura a una ubicación son del mismo tamaño. "

Answer 3

Para la sincronización de hilos, se recomienda utilizar una de las clases EventWaitHandle, como ManualResetEvent. Si bien es marginalmente más simple emplear un indicador booleano simple como lo hace aquí (y sí, querría marcarlo como volatile), IMO es mejor usar la herramienta de enhebrar.Para sus propósitos, que haría algo como esto ...

private System.Threading.ManualResetEvent threadStop; 

void StartThread() 
{ 
    // do your setup 

    // instantiate it unset 
    threadStop = new System.Threading.ManualResetEvent(false); 

    // start the thread 
} 

En el hilo ..

while(!threadStop.WaitOne(0) && !operationComplete) 
{ 
    // work 
} 

Luego, en la interfaz gráfica de usuario para cancelar ...

threadStop.Set(); 

Answer 4

Look hasta Interlocked.Exchange(). Hace una copia muy rápida en una variable local que se puede usar para comparar. Es más rápido que lock().

Answer 5

No es necesario bloquear porque tiene un escenario de escritor único y un campo booleano es una estructura simple sin riesgo de corromper el estado (while it was possible to get a boolean value that is neither false nor true). Pero debe marcar el campo como volatile para evitar que el compilador realice algunas optimizaciones. Sin el modificador volatile, el compilador podría almacenar en caché el valor de un registro durante la ejecución de su bucle en su hilo de trabajo y, a su vez, el bucle nunca reconocería el valor modificado. Este artículo de MSDN (How to: Create and Terminate Threads (C# Programming Guide)) soluciona este problema. Si bien es necesario bloquear, un bloqueo tendrá el mismo efecto que marcar el campo volatile.