2011-07-01 11 views
11

Si una sola variable de 32 bits se comparte entre varios subprocesos, ¿debo poner un bloqueo de exclusión mutua alrededor de la variable? Por ejemplo, supongamos que 1 hilo escribe en un contador de 32 bits y lo lee un segundo hilo. ¿Hay alguna posibilidad de que el segundo hilo pueda leer un valor dañado?¿Debo bloquear mutex una sola variable?

Estoy trabajando en un sistema embebido ARM de 32 bits. El compilador siempre parece alinear las variables de 32 bits para que puedan leerse o escribirse con una sola instrucción. Si la variable de 32 bits no estaba alineada, entonces la lectura o escritura se dividiría en varias instrucciones y el segundo subproceso podría leer un valor dañado.

¿La respuesta a esta pregunta cambia si cambio a un sistema de núcleo múltiple en el futuro y la variable se comparte entre los núcleos? (suponiendo un caché compartido entre los núcleos)

¡Gracias!

+3

¿Le importan las carreras o le preocupa que se rompa? –

+2

Una vez que se haya asegurado de que la rotura no ocurre, recuerde no escribir 'i ++', o 'i + = j' sin un mutex. –

+1

Gracias por el comentario sobre lagrimeo: no sabía que así se llamaba. Me pregunto qué es "estándar" y/o qué es "buena práctica" para evitar las condiciones de desgarro y carrera. – Will

Respuesta

8

Un mutex lo protege de algo más que rasgarse: por ejemplo, algunas implementaciones de ARM usan ejecución fuera de orden, y un mutex incluirá barreras de memoria (y compilador) que pueden ser necesarias para la corrección de su algoritmo.

Es más seguro incluir el mutex, y luego encontrar la manera de optimizarlo más adelante si se muestra como un problema de rendimiento.

Tenga en cuenta también que si su compilador está basado en GCC, puede tener acceso al GCC atomic builtins.

+0

Gracias por todos los detalles. Leyendo http://www.usenix.org/event/hotpar11/tech/final_files/Boehm.pdf me convenció de que tienes razón. – Will

3

No necesita mutex. En ARM de 32 bits, escritura simple o lectura es una operación atómica. (independientemente de la cantidad de núcleos) Por supuesto, debe declarar esa variable como volátil.

+1

Para mi caso simple anterior creo que esto tiene sentido. Sin embargo, el comentario de David Heffernan sobre lagrimeo me llevó a http://www.usenix.org/event/hotpar11/tech/final_files/Boehm.pdf. Ese documento me pone mucho más nervioso acerca de las razas de datos benignos y de qué tan "volátil" puede no ser una solución completa. – Will

4

Si toda la escritura se realiza a partir de un hilo (es decir, otros hilos solo están leyendo), entonces no es necesario un mutex. Si más de un hilo puede escribir, entonces lo hace.

1

En un sistema de 32 bits, las lecturas y escrituras de vars de 32 bits son atómicas. Sin embargo, depende de qué más esté haciendo con la variable. P.ej. si lo manipula de alguna manera (por ejemplo, agrega un valor), entonces esto requiere una lectura, manipulación y escritura. Si la CPU y el compilador no son compatibles con una operación atómica para esto, entonces deberá usar un mutex para proteger esta secuencia de operaciones múltiples.

Existen otras técnicas sin cerradura que pueden reducir la necesidad de mutexes.

+0

¿existe una operación de "movimiento" no atómico? Creía que cada instrucción de máquina que actualiza el valor de una ubicación de memoria sería atómica y todo lo que importa es el hecho de que un hilo puede leer un valor antiguo en lugar del actual (en el caso de una escritura de hilo, el otro solo lectura, por supuesto) – ShinTakezou

+0

@ShinTakezou - ARM generará una lectura/escritura no atómica si una variable de 32 bits no está alineada. (es decir., hará 4 cargas de bytes en lugar de una carga de palabra para evitar una excepción de acceso no alineado) – Will

+0

¿ARM o el compilador? Supongo que depende del compilador generar el código correcto; y dado que el compilador "sabe" que de hecho está generando 4 instrucciones en lugar de una para una sola escritura, podría poner "barreras" para hacer que la escritura completa sea atómica y evitar que el programador C tenga que preocuparse por los detalles del hardware. la fuente está compilada para (tal vez debe haber una opción para desactivar estas barreras, pero para mí deberían agregarse por defecto, si es posible, por supuesto, y supongo que debería ser) – ShinTakezou

Cuestiones relacionadas