Secciones críticas con procesadores multinúcleo

Question

Con un procesador de un solo núcleo, donde todos sus hilos se ejecutan desde una sola CPU, la idea de implementar una sección crítica usando una operación atómica de prueba y ajuste en algún mutex (o semáforo o etc.) en la memoria parece bastante sencillo; Debido a que su procesador está ejecutando un test-and-set desde un punto en su programa, necesariamente no puede estar haciendo uno desde otro lugar en su programa disfrazado como algún otro hilo.

Pero, ¿qué sucede cuando realmente tiene más de un procesador físico? Parece que la simple atomicidad del nivel de instrucción no sería suficiente, b/c con dos procesadores que potencialmente ejecutan sus operaciones de prueba y configuración al mismo tiempo, lo que realmente necesita para mantener la atomicidad es el acceso a la ubicación de memoria compartida del mutex (Y si la ubicación de la memoria compartida está cargada en la memoria caché, también está todo el problema de consistencia del caché ...)

Parece que esto implicaría mucho más sobrecarga que la carcasa de un solo núcleo, así que aquí está la carne de la pregunta: ¿cuánto peor es? ¿Es peor? ¿Vivimos solo con eso? ¿O lo evitas aplicando una política que todos los hilos dentro de un grupo de procesos tienen que vivir en el mismo núcleo físico?

Answer 1

Los sistemas multi-core/SMP no son solo varias CPU pegadas entre sí. Existe un apoyo explícito para hacer cosas en paralelo. Todas las primitivas de sincronización se implementan con la ayuda de hardware a lo largo de las líneas atomic CAS. La instrucción bloquea el bus compartido por las CPU y el controlador de memoria (y los dispositivos que hacen DMA) y actualiza la memoria, o simplemente actualiza la memoria basándose en cache snooping. Esto a su vez provoca que el algoritmo cache coherency se active forzando a todas las partes involucradas a vaciar sus cachés.

Renuncia - esta es la descripción muy básica, hay cosas más interesantes aquí, como Virtual vs cachés físicas, políticas de caché de escritura, los modelos de memoria, vallas, etc., etc.

Si usted quiere saber más acerca de cómo El sistema operativo puede usar estas instalaciones de hardware: aquí está an excellent book sobre el tema.

Answer 2

Necesitará una prueba y configuración que obligue al procesador a notificar a todos los demás núcleos de la operación para que lo sepan. Sí, eso introduce una sobrecarga y tienes que vivir con eso. Es una razón para diseñar aplicaciones multiproceso de tal manera que no esperen con demasiada frecuencia las primitivas de sincronización.

Answer 3

Bueno, dependiendo del tipo de computadoras que tenga en la casa, haga lo siguiente: Escriba una aplicación multiproceso simple. Ejecute esta aplicación en un solo núcleo (Pentium 4 o Core Solo) y luego ejecútelo en un procesador multinúcleo (Core 2 Duo o similar) y vea qué tan grande es la velocidad.

De acuerdo, estas son comparaciones injustas, ya que Pentium 4 y Core Solo son mucho más lentos independientemente de los núcleos que Core 2 Duo. Tal vez se pueda comparar entre un Core 2 Duo y un Core 2 Quad con una aplicación que puede usar 4 o más hilos.

Usted aumenta una cantidad de puntos válidos. Varios procesadores introducen muchos dolores de cabeza y sobrecarga. Sin embargo, solo tenemos que vivir con ellos, ya que el aumento de la velocidad del paralelismo puede sobrepasarlos, si las secciones críticas se hacen lo suficientemente largas.

En cuanto a su sugerencia final sobre tener todos los hilos en el mismo núcleo físico, eso derrota por completo el punto de una computadora multi-core!

Answer 4

¿O lo soslayan aplicando una política que todos los hilos dentro de un grupo de procesos tienen que vivir en el mismo núcleo físico?

Eso cancelaría todo el punto del multihilo. Cuando usa un bloqueo, semáforo u otras técnicas de sincronización, confía en el sistema operativo para asegurarse de que estas operaciones estén enclavadas, sin importar cuántos núcleos esté utilizando.

El tiempo para cambiar a un hilo diferente después de que se ha liberado un bloqueo está determinado principalmente por el costo de un cambio de contexto. This El subproceso SO trata de la sobrecarga de conmutación de contexto, por lo que es posible que desee comprobarlo.

hay algunos otros temas interesantes también: la

• What are the differences between various threading synchronization options in C#?
• Threading best practices

usted debe leer este artículo de MSDN también: Understanding the Impact of Low-Lock Techniques in Multithreaded Apps.

Answer 5

El proveedor de multi-core cpus tiene que cuidar que los diferentes núcleos se coordinen cuando ejecutan instrucciones que garantizan el acceso a la memoria atómica.

En los chips de Intel, por ejemplo, tiene la instrucción 'cmpxchg'. Compara el valor almacenado en una ubicación de memoria con un valor esperado y lo intercambia por el nuevo valor si los dos coinciden. Si lo antecede con la instrucción 'bloqueo', se garantiza que será atómico con respecto a todos los núcleos.

Answer 6

Los accesos a memoria son manejados por el controlador de memoria que debe ocuparse de problemas multinúcleo, es decir, no debe permitir el acceso simultáneo a las mismas direcciones (probablemente manejadas por memoria o línea de memoria). De modo que puede usar un indicador para indicar si otro procesador está actualizando el contenido de la memoria de algún bloque (esto para evitar un tipo de lectura sucia donde se actualiza parte del registro, pero no todos).

Una solución más elegante es usar un bloque de semáforo HW si el procesador tiene dicha característica. Un semáforo HW es una cola simple que podría ser de tamaño no_of_cores -1. Así es como está en el procesador 6487/8 de TI. Puede consultar el semáforo directamente (y hacer un bucle hasta que se libere) o realizar una consulta indirecta que dará lugar a una interrupción una vez que su núcleo obtenga el recurso. Las solicitudes se ponen en cola y se sirven en el orden en que se hicieron. Una consulta de semáforo es una operación atómica.

La consistencia de la caché es otro problema y es posible que tenga que realizar reescritos de caché y actualizaciones en algunos casos. Pero esto es algo muy específico de implementación de caché. Con 6487/8 necesitábamos hacer eso en algunas operaciones.