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

Presentación del tema: "UPV-EHU / ATC Arquitecturas Paralelas 12-131 4. Sincronización de procesos en sistemas SMP - Introducción - Exclusión mutua - Sincronización mediante eventos."— Transcripción de la presentación:

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

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

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

4 UPV-EHU / ATC Arquitecturas Paralelas 12-134  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 → eventos (productor/consumidor) global → barreras Introducción

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

6 UPV-EHU / ATC Arquitecturas Paralelas 12-136 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 : 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.

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

8 UPV-EHU / ATC Arquitecturas Paralelas 12-138 T&S - Swap 1.1Test&Set ▪ T&S R1,S R1 := MEM[S]; MEM[S] := 1; lock:T&S R1,S BNZ R1,lock RET unlock:ST S,R0 RET

9 UPV-EHU / ATC Arquitecturas Paralelas 12-139 T&S - Swap 1.2Swap ▪ SWAP R1,S R1 MEM[S]; lock:ADDIR1,R0,#1 l1:SWAPR1,S BNZ R1,l1 RET unlock:ST S,R0 RET

10 UPV-EHU / ATC Arquitecturas Paralelas 12-1310 T&S - Swap En sistemas SMP es muy importante mantener el tráfico limitado.  Tráfico La instrucción T&S escribe siempre en el cerrojo; incluso cuando el cerrojo está cerrado; por lo tanto, se invalida el bloque que 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.

11 UPV-EHU / ATC Arquitecturas Paralelas 12-1311 TS/INV] S=0,INV P0 P1 ? P2 ? P3 ? P4 ? TS/INV] x P0 está en SC BRQ = pedir bloque / x = invalidado / control del bus = FIFO x BRQ....... x BRQ......... x BRQ... repetir! SC x x x x [TS BRQ [TS BRQ.......... [TS BRQ................... [TS BRQ............................ [TS.. TS/INV] [TS.. TS/INV] [TS... TS/INV] [TS.. T&S – Swap: simulación del tráfico

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

13 UPV-EHU / ATC Arquitecturas Paralelas 12-1313 Test-and-T&S 2 Procedimiento Test-and-Test&Set  Mejoras para minimizar el tráfico lock:LD R1,S BNZ R1,lock T&S R1,S BNZ R1,lock RET 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 ).

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

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

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

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

18 UPV-EHU / ATC Arquitecturas Paralelas 12-1318 LL – SC / C&Swap 2.2Compare&Swap ▪ C&S R1,R2,S si (R1 = MEM[S]) MEM[S] R2; lock:ADDI R2,R0,#1 l1:C&S R0,R2,S BNZ R2,l1 RET

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

20 UPV-EHU / ATC Arquitecturas Paralelas 12-1320 Tickets 1 Tickets  Alternativas para reducir el tráfico F&I R1,TICKET tick:LL R1,TICKET ADDI R2,R1,#1 SC TICKET,R2 BZ R2, tick 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.

21 UPV-EHU / ATC Arquitecturas Paralelas 12-1321 Tickets 1 Tickets lock:F&I R1,TICKET l1:LD R2,TURNO SUB R3,R1,R2 BNZ R3, l1 RET unlock: LD R1,TURNO ADDI R1,R1,#1 ST TURNO,R1 RET Tráfico: - cuando se obtiene el ticket - cuando se actualiza la variable turno  Alternativas para reducir el tráfico

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

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

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

25 UPV-EHU / ATC  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 (sin límite) Test-and-Test&SetP(3P-1)/270 bloques LL - SC P 2 49 bloques TicketsP(P+3)/235 bloques Vector de cerrojos3P21 bloques Resumen

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

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

28 UPV-EHU / ATC Arquitecturas Paralelas 12-13 28 Barreras Una barrera sencilla ( B, un struct de tipo 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); }

29 UPV-EHU / ATC Arquitecturas Paralelas 12-13 29 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); }

30 UPV-EHU / ATC Arquitecturas Paralelas 12-1330 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, 4P (sin contención en la entrada)

31 UPV-EHU / ATC Arquitecturas Paralelas 12-1331 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...

32 UPV-EHU / ATC Arquitecturas Paralelas 12-1332 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.