sections, single, master y barreras

💡 En simple

• sections: en la cocina, uno pica verduras y otro hace el arroz. Son tareas distintas en paralelo (no el mismo bucle repartido).
• single: “que alguien (cualquiera) conteste el teléfono”, y los demás esperan a que cuelgue.
• master: “que lo haga el jefe” (hilo 0); los demás no lo esperan.
• barrier: “nadie sale a recreo hasta que todos terminen”.

sections: tareas distintas en paralelo

Cada section la ejecuta un hilo, una sola vez; secciones distintas pueden ir en hilos distintos. Es paralelismo funcional (distintas tareas), a diferencia de for (mismo trabajo sobre datos distintos). Hay barrera implícita al final, salvo nowait.

Ejemp03_sections_omp.cpp

#pragma omp parallel num_threads(4) shared(a, b, c, d) private(i, id)
{
    // ¿se puede usar nowait?
    #pragma omp sections nowait
    {
        #pragma omp section
        {
            for (i = 0; i < N; i++) {
                c[i] = a[i] + b[i];
                printf("seccion 1. Hilo: %i it: %i \n ", omp_get_thread_num(), i);
            }
        }
        #pragma omp section
        {
            for (i = 0; i < N; i++) {
                d[i] = a[i] * b[i];
                printf("seccion 2. Hilo: %i it: %i \n ", omp_get_thread_num(), i);
            }
        }
    }
}

Con 4 hilos, solo 2 trabajan (hay 2 secciones); los otros 2 no tienen nada que hacer. Cada sección completa la hace un único hilo (en una corrida: la sección 1 fue del hilo 1, de it: 0 a it: 19).

¿nowait aquí?

Sí: después de sections no hay más trabajo dentro de la región, y el cierre de parallel ya tiene su propia barrera. Las dos secciones no dependen entre sí (c y d son arreglos distintos).

firstprivate en sections (U4.3)

Con sections firstprivate(section_count) y dos secciones que hacen section_count++: si las ejecutan hilos distintos, ambas imprimen 1; si el mismo hilo ejecuta las dos, imprime 1 y luego 2 (su copia privada se reutiliza).

single y master

	single	master
¿Quién lo ejecuta?	cualquier hilo (el primero que llega)	solo el hilo 0
¿Los demás esperan al final?	sí (barrera implícita), salvo nowait	no
¿Acepta cláusulas?	private, firstprivate, copyprivate, nowait	ninguna
Uso típico	E/S, inicializar algo compartido	reportes de avance

Ejemp04_single_omp.cpp

#pragma omp parallel
{
    #pragma omp single nowait
    {
        a = 10;
        id = omp_get_thread_num();
        b[id] = a;
        cout << "constructor Single ejecutado por el hilo " << id << endl;
    }
}

Salida real (4 hilos): constructor Single ejecutado por el hilo 3 y luego solo b[3] = 10; el resto de b sigue en -1. En otra corrida puede ser otro hilo: no se sabe cuál entra a un single.

Barreras: explícita e implícitas

#pragma omp barrier: cada hilo que llega espera a todos los del equipo. Además hay barreras implícitas (y con ellas un flush) al final de:

• parallel (siempre, es el join),
• for, sections, single (salvo nowait).

No hay barrera al final de master ni de critical.

Cómo leerlo: el tiempo avanza a la derecha. Los tres hilos hacen su parte del for; los que terminan antes esperan (rojo claro) en la barrera implícita del for. Luego un solo hilo (el 0 en este ejemplo, podría ser cualquiera) ejecuta el single y los otros esperan en su barrera. El master lo hace solo el hilo 0 y no tiene barrera: los hilos 1 y 2 siguen de largo.

¿Quién espera a quién? Barreras implícitas

Arma el cuerpo de un #pragma omp parallel y mira dónde se frenan los hilos. Rojo = esperando.

LibreU4.3: single con mensajes de avanceEjemp01_master: una vuelta del do-whileEjemp05: contar ceros (for + critical)Ejemp03: sections nowaithilos = 4🎲 Otros tiempos▶︎ Ejecutar

1.forsectionssinglemastercriticalbarrier nowait✕

2.forsectionssinglemastercriticalbarrier nowait✕

3.forsectionssinglemastercriticalbarrier nowait✕

+ constructor

tiempo de la región10.1

tiempo perdido esperando (todos)13.2

barreras4

• for: barrera implícita al final (quítala con nowait).
• single: un hilo trabaja; los demás esperan al final (salvo nowait).
• El cierre de parallel siempre tiene barrera (es el join).

Barrera dentro de una función (U4.2)

Una barrier se enlaza con la región parallel más cercana que la contiene en tiempo de ejecución, aunque esté escrita en otra función (en el ejemplo, la barrera de sub3 pertenece a la región paralela abierta en sub2). Todos los hilos de ese equipo deben llegar a ella.

Ejemp01_master.c: single + reduction + master en un bucle

sesionb/Ejemp01_master.c

#pragma omp parallel num_threads(4)
{
    do {
        #pragma omp for
        for (i = 1; i < n-1; ++i) xold[i] = x[i];          // barrera al final
        #pragma omp single
        { toobig = 0; }                                    // uno reinicia; barrera al final
        #pragma omp for private(y, error) reduction(+:toobig)
        for (i = 1; i < n-1; ++i) {
            y = x[i];
            x[i] = average(xold[i-1], x[i], xold[i+1]);    // suavizado (como el PD01)
            error = y - x[i];
            if (error > tol || error < -tol) ++toobig;
        }                                                  // barrera: toobig ya sumado
        #pragma omp master
        ++c;                                               // solo el hilo 0 cuenta vueltas
    } while (toobig > 0);
}

Salida real (n = 512, tol = 0.01): iteration 12385, toobig=0.

• single reinicia toobig una vez y su barrera garantiza que nadie empieza a sumar antes.
• reduction(+:toobig) cuenta en paralelo sin carrera.
• master incrementa c sin barrera: solo el hilo 0 lo hace.

Ejercicio

En Ejemp01_master.c, ¿qué pasaría si toobig = 0 se hiciera con master en vez de single?

Ver solución

master no tiene barrera: otros hilos podrían empezar el siguiente for con reduction(+:toobig) antes de que el hilo 0 ponga toobig = 0. La lámina de U4.2 sobre reduction muestra exactamente ese error: la inicialización tiene que quedar antes de la reducción, con una barrier después del master, usando single (que trae barrera) o inicializando antes de la región paralela.

Errores típicos

• Creer que master tiene barrera al final. No la tiene; single sí (salvo nowait).
• Decir que single lo ejecuta el hilo 0. Lo ejecuta el primero que llega; el que siempre es el 0 es master.
• Poner un barrier dentro de un if (id == 0), un single o un master: no todos los hilos llegan y el programa se cuelga (o el comportamiento no está definido).
• Esperar que con 2 hilos y 3 section corran las 3 a la vez: un hilo hace dos, una detrás de otra.

Práctica extra

Tres section que tardan 2 s, 1 s y 1 s. ¿Cuánto tarda el bloque sections con 1, 2 y 3 hilos? ¿Cuál es el speedup máximo?

Ver solución

• 1 hilo: 2 + 1 + 1 = 4 s.
• 2 hilos: el mejor reparto es un hilo con la de 2 s y el otro con las dos de 1 s → 2 s.
• 3 hilos: una sección por hilo → 2 s (manda la más larga).

S_máx = 4/2 = 2, aunque haya 3 hilos: el tiempo nunca baja de la sección más larga. Es el mismo argumento del camino crítico de un DAG.

Autoevaluación

0/5 correctas · 0 respondidas Reiniciar

1. ¿Qué constructor NO tiene barrera implícita al final?

a) forb) singlec) masterd) sections

2. 3 secciones y 8 hilos: ¿cuántos hilos trabajan dentro de sections?

a) 8b) como máximo 3c) 1d) 4

3. single lo ejecuta…

a) siempre el hilo 0b) cualquier hilo (el primero que llega)c) todosd) el último hilo

4. Para que los demás no esperen al terminar un single se usa…

a) masterb) nowaitc) barrierd) flush

5. sections es paralelismo…

a) de datosb) funcional (tareas distintas)c) de instruccionesd) distribuido

Fuente ·U4.1 Paralelismo compartido-OMP.pdf (láminas 18–22, 25) · U4.2 Paralelismo compartido-OMP.pdf (master, barrier) · U4.3 Paralelismo compartido-OMP.pdf (sections, single) · semana_9/Ejemp03_sections_omp.cpp · semana_9/Ejemp04_single_omp.cpp · semana_9/sesionb/Ejemp01_master.c