UPV-EHU / ATC Arquitecturas Paralelas 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 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”.

UPV-EHU / ATC Arquitecturas Paralelas 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!!!

UPV-EHU / ATC Arquitecturas Paralelas  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

UPV-EHU / ATC Arquitecturas Paralelas  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

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

UPV-EHU / ATC Arquitecturas Paralelas 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) ?

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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

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

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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)

UPV-EHU / ATC Arquitecturas Paralelas 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 ).

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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!

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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;

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

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas Vectores de cerrojos 2 Vectores de cerrojos Proceso en SC ÍNDICE : Siguiente posición de espera VC 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

UPV-EHU / ATC Arquitecturas Paralelas 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

UPV-EHU / ATC Arquitecturas Paralelas 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 → → 3P VC(I+1)=0,INV P0 P1 LD.. P2 LD.... P3 LD.... P4 LD.... LD x BRQ SC

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

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

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

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

UPV-EHU / ATC Arquitecturas Paralelas 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 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)

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