OpenMP — memoria compartida y fork-join

💡 En simple

Con MPI cada proceso es una casa separada: para compartir algo hay que mandar una carta (un mensaje). Con OpenMP todos los trabajadores están en la misma oficina y miran la misma pizarra (la memoria compartida). No hay cartas, pero hay otro problema: si dos escriben a la vez en la misma parte de la pizarra, se pisan.

En una frase: OpenMP reparte el trabajo de un programa entre varios hilos que comparten la memoria, agregando unas pocas líneas #pragma al código secuencial.

¿Qué es OpenMP?

OpenMP (Open Multi-Processing) es una API para programar en paralelo con memoria compartida, en C/C++ y Fortran. Tiene tres piezas:

Pieza	Para qué	Ejemplo
Directivas de compilador (#pragma omp …)	Abrir regiones paralelas, repartir bucles, sincronizar	#pragma omp parallel for
Librería (omp.h)	Preguntar o fijar número e id de hilos, medir tiempo	omp_get_thread_num(), omp_get_wtime()
Variables de entorno	Controlar la ejecución sin recompilar	OMP_NUM_THREADS=4, OMP_SCHEDULE

Las directivas son “comentarios con significado”: si compilas sin -fopenmp, el compilador las ignora y el programa corre secuencial. Por eso el código del curso protege las llamadas a la librería con #ifdef _OPENMP.

• Dónde corre: una sola máquina con memoria compartida (UMA o ccNUMA): un socket/CPU o un nodo con varios sockets. No sirve entre nodos de un clúster (eso es memoria distribuida → MPI).
• Hilo (thread): la unidad de ejecución más pequeña que el sistema operativo puede planificar. Tú decides cuántos.

Modelo fork-join

1. El programa arranca con un solo hilo: el hilo maestro (master, id 0).
2. FORK: al encontrar #pragma omp parallel, el maestro crea un equipo de hilos que ejecutan el bloque.
3. JOIN: al cerrar el bloque hay una barrera implícita: todos esperan al más lento, el equipo desaparece y solo sigue el maestro.

OpenMP: modelo fork-join y la primera condición de carrera

Fork → trabajo → JoinEjemp01: ¿shared o private?

hilos = 4regiones paralelas = 2🎲 Otra carga

⏮︎◀︎▶︎ Play▶︎⏭︎

0.5×1×2×4×

fase 0/7

Solo existe el hilo maestro (hilo 0) ejecutando código serial.

Error común: la primera condición de carrera

En Ejemp01_hello_omp.cpp, si id es compartida, todos los hilos escriben en la misma variable y luego la leen: imprimen el número del último que escribió. La solución es private(id) (o declarar int id dentro del bloque, que la hace privada). Pruébalo en la pestaña «Ejemp01» de arriba.

OpenMP vs MPI

	OpenMP	MPI
Memoria	compartida (una máquina)	distribuida (muchos nodos)
Unidad	hilos	procesos
Comunicación	leer/escribir variables compartidas	mensajes (Send/Recv, colectivas)
Esfuerzo para empezar	bajo: agregar #pragma a un código que ya funciona	alto: reescribir el programa
Techo de rendimiento	limitado por los núcleos de un nodo	escala a todo el clúster
Riesgo típico	condiciones de carrera	deadlocks

Cómo leerlo: a la izquierda los 4 hilos tienen cada uno su pila (ahí viven las variables privadas, como id o el índice i), pero todos apuntan a la misma memoria: si dos escriben a la vez la misma variable hay carrera. A la derecha cada proceso MPI tiene su propia memoria; para que otro vea un dato hay que mandarlo en un mensaje.

La lámina “OMP vs MPI” lo resume con una curva rendimiento vs esfuerzo: OpenMP sube rápido pero se aplana (se acaban los núcleos). MPI cuesta más al inicio (“el código no funciona” durante un tramo) pero llega más alto, y OpenMP + MPI (programación híbrida) llega todavía más arriba.

En el examen…

Si preguntan cuándo usar cada uno: OpenMP para paralelizar rápido dentro de un nodo; MPI cuando el problema no cabe o no escala en un nodo; híbrido en clústeres de nodos multinúcleo (MPI entre nodos, OpenMP dentro de cada nodo).

Compilar y ejecutar

g++ -fopenmp Ejemp01_hello_omp.cpp -o hello      # sin -fopenmp, los #pragma se ignoran
OMP_NUM_THREADS=4 ./hello                        # o omp_set_num_threads(4) en el código

Ejemp01_hello_omp.cpp

#include <iostream>
#include <unistd.h>
#ifdef _OPENMP
#include <omp.h>
#endif

int main() {
    int id = -1, x = 10;
#pragma omp parallel shared(x) private(id)
    {
#ifdef _OPENMP
        id = omp_get_thread_num();      // 0, 1, 2, ... en cada hilo
#endif
        sleep(1);                         // fuerza la carrera si id fuera shared
        printf("Peekaboo desde el hilo = %d \n", id);
    }
}

Con 4 hilos imprime 4 líneas Peekaboo desde el hilo = 0…3 en un orden distinto cada vez: los hilos no tienen orden garantizado.

Ejercicio

¿Qué cambia si quitas private(id) y dejas el sleep(1)? ¿Y si además quitas el sleep?

Ver solución

Sin private(id), id es compartida (por defecto las variables declaradas fuera de la región son shared). Con el sleep(1), todos los hilos escriben su número casi a la vez, duermen 1 s y luego leen: todos imprimen el valor del último que escribió (por ejemplo, cuatro veces = 3). Sin el sleep la carrera sigue existiendo, pero es más difícil de ver: a veces sale bien y a veces no. Que funcione una vez no prueba que sea correcto.

Errores típicos

• Creer que #pragma omp parallel reparte el trabajo. Solo crea el equipo: todos los hilos ejecutan el bloque completo. Para repartir las iteraciones hace falta for (o parallel for).
• Olvidar -fopenmp: compila sin error y corre con un hilo. Si el speedup es exactamente 1, revisa esto primero.
• Esperar que los hilos impriman en orden. No hay orden garantizado entre hilos.
• Querer usar OpenMP entre nodos de un clúster: ahí no hay memoria compartida, hace falta MPI.

Práctica extra

Con este código, ¿cuántas veces sale cada letra y qué orden está garantizado?

printf("A\n");
#pragma omp parallel num_threads(3)
{
    printf("B\n");
    #pragma omp single
    printf("C\n");
}
printf("D\n");

Ver solución

A 1 vez (antes del fork, solo el maestro), B 3 veces (cada hilo), C 1 vez (single: un hilo cualquiera), D 1 vez (después del join).

Garantizado: A es la primera y D la última (el join es una barrera). Las tres B y la C se mezclan, con una sola regla: la C sale después de la B del hilo que la imprime.

Autoevaluación

0/5 correctas · 0 respondidas Reiniciar

1. OpenMP sirve para paralelizar…

a) entre nodos de un clústerb) dentro de una máquina con memoria compartidac) solo en GPUd) solo en Fortran

2. Al cerrar la llave de #pragma omp parallel ocurre…

a) nadab) un forkc) una barrera implícita (join)d) un MPI_Barrier

3. Si compilas sin -fopenmp…

a) no compilab) los #pragma se ignoran y corre secuencialc) usa 2 hilosd) falla al ejecutar

4. Una variable declarada antes de la región paralela es, por defecto…

a) privateb) firstprivatec) sharedd) threadprivate

5. El hilo maestro tiene id…

a) 0b) 1c) -1d) el último

Fuente ·U4.1 Paralelismo compartido-OMP.pdf (láminas 2–12) · semana_9/Ejemp01_hello_omp.cpp