En una aplicación C ++ multiproceso, ¿necesito un mutex para proteger un booleano simple?

Question

Tengo una aplicación C ++ multiproceso que realiza renderizado 3D con la biblioteca OpenSceneGraph. Estoy planeando iniciar el bucle de renderizado de OSG como un hilo separado usando boost :: hilos, pasando una estructura de datos que contiene el estado compartido en el hilo. Estoy tratando de evitar algo demasiado pesado (como mutexes) para la sincronización, ya que el bucle de renderizado debe ser bastante ajustado, y el propio OSG intenta evitar tener que bloquearlo. La mayor parte del estado compartido se establece antes de que se inicie el subproceso y nunca cambia. Tengo algunos datos que necesitan ser cambiados, que estoy planeando duplicar. Sin embargo, tengo un booleano simple para indicarle al hilo que suspenda el renderizado, y luego reanude el renderizado, y otro para eliminarlo. En ambos casos, el hilo de la aplicación establece el bool, y el hilo de renderizado solo lo lee. ¿Necesito sincronizar el acceso a estos bools? Por lo que puedo decir, lo peor que podría pasar es que el bucle de renderizado continúe durante un marco adicional antes de suspender o salir.

Answer 1

En C ++ 11 y posterior, que tiene concurrencia definida por estándares, use std::atomic<bool> para este propósito. De http://en.cppreference.com/w/cpp/atomic/atomic:

  

Si un hilo escribe en un objeto atómico mientras otro lo lee, el comportamiento está bien definido (consulte el modelo de memoria para obtener detalles sobre las carreras de datos).

---

La siguiente respuesta anterior puede haber sido cierta en algún momento en el pasado con algunos compiladores y algunos entornos operativos, pero hoy no se debe confiar en ella:

Tienes razón, en este caso no necesitarás sincronizar los bools. Sin embargo, debe declararlos volatile, para asegurarse de que el compilador realmente los lea de la memoria cada vez, en lugar de almacenar en caché la lectura anterior en un hilo (es una explicación simplificada, pero debería hacerlo para este propósito).

La siguiente pregunta tiene más información sobre esto: Hilo C ++, datos compartidos

Answer 2

¿Por qué no simplemente usar una variable entrelazada ?

Answer 3

En cuanto a C ++ 11 y posterior, finalmente reconoce los subprocesos y establece claramente que modificar un bool (u otra variable no atómica) en un subproceso y acceder al mismo tiempo en otro es un comportamiento indefinido. En su caso, usar std::atomic<bool> debería ser suficiente para que su programa sea correcto, evitando que use bloqueos.
No use volatile . No tiene nada que ver con hilos. Para obtener más información, consulte ¿Puedo leer un bool? variable en un hilo sin mutex?

Answer 4

No creo que necesite aquí un mutex completo, aunque el hilo de renderizado tendrá que esperar ocupado en el estado 'suspendido' si no está utilizando un objeto de sincronización que admita una espera primitiva.

Sin embargo, debe considerar el uso de las diversas primitivas de intercambio entrelazadas (InterlockedExchange en Windows). No porque las lecturas / escrituras del bool no sean atómicas, sino para garantizar que no haya comportamientos extraños, el compilador que reordena la memoria accede en un solo hilo.

Answer 5

Este hilo tiene un poco más de información y discusión sobre seguridad de hilos, especialmente para tipos de datos simples:

¿Cómo puedo crear un hilo- ¿patrón único seguro en Windows?