4 Sincronizacin de procesos en sistemas SMP Introduccin

4. Sincronización de procesos en sistemas SMP - Introducción - Exclusión mutua - Sincronización mediante eventos - Sincronización mediante barreras UPV-EHU / ATC Arquitecturas Paralelas 12 -13 1

Introducción La memoria de los sistemas SMP es compartida y los procesos se comunican por medio de variables compartidas. En la mayoría de aplicaciones, hay que sincronizar la utilización de las variables para que el significado del programa sea “lógico”. Pi. . . ST A(R 1), F 2. . . UPV-EHU / ATC Arquitecturas Paralelas 12 -13 Pj ? . . . LD F 5, A(R 1). . . 2

Introducción ¿Qué pasará en este caso (CONT = 0)? Pi Pj . . . LD F 1, CONT ADDI F 1, #1 ST CONT, F 1. . . LD. . ADDI. . ST UPV-EHU / ATC Arquitecturas Paralelas 12 -13 CONT = 1!!! 3

Introducción Necesitamos accesos a memoria atómicos (sin interferencias) para poder sincronizar procesos. Sincronizaciones de dos tipos: - Secciones críticas trozos de código que se tienen que ejecutar en exclusión mutua (un solo proceso al mismo tiempo). - Sincronización mediante eventos punto a punto global UPV-EHU / ATC Arquitecturas Paralelas 12 -13 → eventos (productor/consumidor) → barreras 4

Introducción Los procesos quedarán en espera hasta que ocurra algo; es decir se perderá tiempo. Para esperar un intervalo de tiempo: -- espera activa -- bloqueo Características de los mecanismos de sincronización: - Latencia baja - Tráfico limitado UPV-EHU / ATC Arquitecturas Paralelas 12 -13 - Buena escalabilidad - Bajo coste de memoria - Igualdad de oportunidades 5

Exclusión mutua Parte de código que sólo debe ser ejecutado por un único procesador simultáneamente, sección crítica. Para controlar la ejecución de la sección crítica: - cerrojos: 0, abierto; 1, cerrado - funciones lock - unlock : UPV-EHU / ATC lock(S): analizar el cerrojo; si está abierto, cerrar y pasar a ejecutar la sección crítica; si no, esperar hasta que se abra el cerrojo. unlock(S): abrir el cerrojo. Arquitecturas Paralelas 12 -13 6

Exclusión mutua lock: LD R 1, S BNZ R 1, lock(S). . . k : = k + 1; . . . ADDI R 2, R 0, #1 ST S, R 2 ? RET unlock(S) unlock: ST S, R 0 RET Sección crítica Necesitamos instrucciones atómicas de tipo RMW. UPV-EHU / ATC Arquitecturas Paralelas 12 -13 7

T&S - Swap 1. 1 Test&Set ▪ T&S R 1, S R 1 : = MEM[S]; MEM[S] : = 1; lock: T&S R 1, S BNZ R 1, lock RET UPV-EHU / ATC Arquitecturas Paralelas 12 -13 unlock: ST S, R 0 RET 8

T&S - Swap 1. 2 Swap ▪ SWAP R 1, S R 1 <--> MEM[S]; lock: ADDI R 1, R 0, #1 l 1: UPV-EHU / ATC SWAP R 1, S BNZ R 1, l 1 RET Arquitecturas Paralelas 12 -13 unlock: ST S, R 0 RET 9

T&S - Swap Tráfico En sistemas SMP es muy importante mantener el tráfico limitado. La instrucción T&S escribe siempre en el cerrojo; incluso cuando el cerrojo está cerrado; por lo tanto, se invalida el bloque contiene el cerrojo una y otra vez. Como consecuencia se genera mucho tráfico de datos cuando hay varios procesos que están esperando a entrar en la sección crítica. UPV-EHU / ATC Arquitecturas Paralelas 12 -13 10

T&S – Swap: simulación del tráfico P 0 está en SC BRQ = pedir bloque / x = invalidado / control del bus = FIFO P 0 S=0, INV SC P 1 ? x [TS BRQ P 2 ? x [TS BRQ. . P 3 ? x [TS BRQ. . . . . P 4 ? x [TS BRQ. . . . TS/INV] x TS/INV][TS. . x BRQ. . . . . TS/INV][TS. . . x BRQ. . . repetir! UPV-EHU / ATC Arquitecturas Paralelas 12 -13 11

T&S with backoff Mejoras para minimizar el tráfico 1 Test&Set with backoff Si el cerrojo está cerrado no intentar entrar una y otra vez: dejar un intervalo de tiempo sin intentarlo. lock: T&S R 1, S BNZ R 1, esperar RET esperar: CALL ESPERA [actualizar t. espera] JMP lock Suele ser adecuado tener tiempos de espera exponenciales: t 0 = k; t 1 = k × c; t 2 = k × c 2; . . . UPV-EHU / ATC Arquitecturas Paralelas 12 -13 (c>1) 12

Test-and-T&S Mejoras para minimizar el tráfico 2 Procedimiento Test-and-Test&Set Dividir la operación lock en dos partes: (a) leer hasta encontrar el cerrojo abierto (LD). (b) intentar cerrar el cerrojo de manera atómica (T&S). UPV-EHU / ATC Arquitecturas Paralelas 12 -13 lock: LD R 1, S BNZ R 1, lock T&S R 1, S BNZ R 1, lock RET 13

Test-and-T&S: simulación de tráfico P 0 S=0, INV P 1 LD x BRQ P 2 LD x BRQ. . . P 3 LD x BRQ. . . . P 4 LD x BRQ. . . LD[TS. . . . TS/INV] LD[TS. . . . x BRQ x SC TS/INV]LD. . x BRQ. . . LD[TS. . . x BRQ. . . . TS/INV]LD. . LD[TS. x BRQ. . . . LD. . . x BRQ. LD. . . TS/INV] LD. . Tráfico de datos (bloques) para que entre un proc. en SC → P + (P-1) + (P-2) para salir de SC → 1 en total → 3 P – 2 P proc. → 3 P 2/2 UPV-EHU / ATC Arquitecturas Paralelas 12 -13 14

LL – SC / C&Swap 2. 1 Load Locked / Store Conditional - La operación atómica se divide en dos partes - Para asegurar la atomicidad se utiliza un flag de hardware ▪ LL R 1, S R 1 : = MEM[S]; LSin [dir] : = S; LSin [flag] : = 1; ▪ SC S, R 1 si (LSin [dir, flag] = S, 1) MEM[S] : = R 1; LSin [flag] : = 0; en todos los proc. (INV) R 1 : = 1; se ha escrito si_no R 1 : = 0 no se ha escrito UPV-EHU / ATC Arquitecturas Paralelas 12 -13 15

LL – SC / C&Swap 2. 1 Load Locked / Store Conditional lock: ADDI R 2, R 0, #1 l 1: LL R 1, S BNZ R 1, l 1. . . SC S, R 2 BZ R 2, lock RET unlock: ST S, R 0 RET Se genera tráfico una única vez, al entrar a la sección crítica; En el resto de los casos no se escribe! UPV-EHU / ATC Arquitecturas Paralelas 12 -13 16

LL- SC: simulación del tráfico P 0 S=0, INV P 1 LL x BRQ P 2 LL x BRQ. . . P 3 LL x BRQ. . . . P 4 LL x BRQ. . . SC LL(1)[SC. . . SC /INV] LL(1)[SC. . . (0)x BRQ LL(1)[SC. . (0)x BRQ. . SC] LL. . . . LL(1)[SC(0)x BRQ. . . . SC] LL. . . Tráfico de datos (bloques) para que entre un proc. en SC → P + (P – 1) para salir de SC → 0 en total → 2 P – 1 P proc. → P 2 UPV-EHU / ATC Arquitecturas Paralelas 12 -13 17

LL – SC / C&Swap 2. 2 Compare&Swap ▪ C&S R 1, R 2, S si (R 1 = MEM[S]) MEM[S]<---> R 2; lock: ADDI R 2, R 0, #1 l 1: C&S R 0, R 2, S BNZ R 2, l 1 RET UPV-EHU / ATC Arquitecturas Paralelas 12 -13 18

Fetch&OP 3 Fetch&Op ▪ Fetch&Incr R 1, A R 1 : = MEM[A] + 1; ▪ Fetch&Dcr R 1, A ▪ Fetch&Add R 1, R 2, A R 1 : = MEM[A] + R 2; UPV-EHU / ATC Arquitecturas Paralelas 12 -13 19

Tickets Alternativas para reducir el tráfico 1 Tickets Idea: ordenar las entradas a las secciones críticas. Dos variables: turno (a quién le corresponde entrar en la SC) y ticket, para conocer tu turno. Antes de entrar, obtener un ticket y después esperar hasta que llegue el turno. F&I UPV-EHU / ATC R 1, TICKET Arquitecturas Paralelas 12 -13 tick: LL R 1, TICKET ADDI R 2, R 1, #1 SC TICKET, R 2 BZ R 2, tick 20

Tickets Alternativas para reducir el tráfico 1 Tickets lock: F&I R 1, TICKET l 1: LD R 2, TURNO SUB R 3, R 1, R 2 BNZ R 3, l 1 RET Tráfico: UPV-EHU / ATC unlock: LD R 1, TURNO ADDI R 1, #1 ST TURNO, R 1 - cuando se obtiene el ticket - cuando se actualiza la variable turno Arquitecturas Paralelas 12 -13 21

Vectores de cerrojos Alternativas para reducir el tráfico 2 Vectores de cerrojos No utilizar la variable compartida TURNO, sino un cerrojo privado por cada proceso. Cada proceso avisa al siguiente. VC 1 1 0 1 1 Proceso en SC UPV-EHU / ATC Arquitecturas Paralelas 12 -13 1 1 ÍNDICE: Siguiente posición de espera 22

Vectores de cerrojos Alternativas para reducir el tráfico 2 Vectores de cerrojos lock: F&I R 1, INDICE l 1: LD R 2, VC(R 1) BNZ R 2, l 1 ST MI_INDICE, R 1 unlock: ADDI R 2, R 0, #1 LD R 1, MI_INDICE ST VC(R 1), R 2 ADDI R 1, #1 ST VC(R 1), R 0 RET Tráfico: Solamente una vez, cuando se actualizan los componentes del vector de cerrojos UPV-EHU / ATC Arquitecturas Paralelas 12 -13 23

Tickets / Vectores de cerrojos: simulación del tráfico P 0 TURNO++, INV P 0 SC P 1 LD x BRQ P 2 LD x BRQ. . . P 3 LD x BRQ. . P 4 LD x BRQ. . . P 1 LD. . x BRQ LD. . . . P 2 LD. . . P 3 LD. . P 4 LD. . LD LD. . . Tráfico de datos (bloques) Tickets → 1+P Vectores de cerrojos → 1 + 1 UPV-EHU / ATC VC(I+1)=0, INV Arquitecturas Paralelas 12 -13 LD SC → P(P+3) / 2 → 3 P 24

Resumen Tráfico para entrar en la sección crítica (un SMP de 8 procesadores; caso peor: P = 7 procesadores están esperando para entrar. ) T&S Test-and-Test&Set (sin límite) P(3 P-1)/2 70 bloques LL - SC P 2 49 bloques Tickets Vector de cerrojos P(P+3)/2 3 P 35 bloques 21 bloques UPV-EHU / ATC

Sincronización mediante eventos 1 Sincronización punto a punto mediante eventos Sincronización habitual entre productor y consumidor mediante un flag. P 1 UPV-EHU / ATC P 2 while (flag == 0); A = F 1(B); flag = 1; B = F 2(A); post(flag); wait(flag); post(flag, i); wait(flag, i); Arquitecturas Paralelas 12 -13 26

Barreras 2 Sincronización mediante barreras Sincronización global: se sincroniza un conjunto de procesos antes de seguir con la ejecución. Estructura de datos “barrera”: struct int int } UPV-EHU / ATC tipo_barrera { S; cont; flag; Arquitecturas Paralelas 12 -13 27

Barreras Una barrera sencilla (B, un struct de tipo_barrera) Barrera (B, P) { LOCK (B. S); if (B. cont == 0) B. flag = 0; B. cont++; mi_cont = B. cont; UNLOCK (B. S) if (mi_cont == P) { B. cont = 0; B. flag = 1; } else while (B. flag == 0); UPV-EHU / ATC } Arquitecturas Paralelas 12 -13 28

Barreras Barrera reutilizable BARRERA (B, P) { val_sal = !(val_sal); LOCK (B. S); B. cont++; mi_cont = B. cont; UNLOCK (B. S) if (mi_cont == P) { B. cont = 0; B. flag = val_sal; } else while (B. flag != val_sal); UPV-EHU / ATC } Arquitecturas Paralelas 12 -13 29

Barreras Eficiencia: tráfico de datos Supogamos que las variables S, cont y flag están en bloques diferentes (para evitar la falsa compartición). En una barrera de P procesos el procesador Pi solicitará los siguientes bloques: - el de S, para ejecutar el lock - el de cont, para el incremento - el de flag, dos veces, al comienzo y al final del bucle de espera. >> total, 4 P UPV-EHU / ATC Arquitecturas Paralelas 12 -13 (sin contención en la entrada) 30

Resumen - Los procesos paralelos necesitan sincronización (a menudo), bien sea para organizar secciones críticas o para “homogeneizar” la ejecución de un conjunto de procesos. - La sincronización debe generar el menor tráfico posible, y tiene que ocurrir lo más rápido posible. - Para crear secciones críticas hacen falta instrucciones especiales, atómicas: T&S / LL-SC. Se pueden utilizar distintas estrategias: Test-and-T&S, tickets, vectores de cerrojos. . . UPV-EHU / ATC Arquitecturas Paralelas 12 -13 31

Resumen - Para sincronizar el productor y el consumidor basta con utilizar un flag (variable compartida). - Hay que utilizar barreras de sincronización para asegurar que los procesos de una aplicación paralela han llegado a cierto punto. Si es posible, las más adecuadas son las barreras que se pueden reutilizar. UPV-EHU / ATC Arquitecturas Paralelas 12 -13 32