4. Sincronización de procesos en sistemas SMP

4.Sincronización de procesos en sistemas SMP - Introducción - Exclusión mutua - Sincronización medianteeventos - Sincronización mediante barreras Arquitecturas Paralelas 12-13

Pi Pj ... LD F5,A(R1) ... ... ST A(R1),F2 ... ? 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”. Arquitecturas Paralelas 12-13

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

Introducción •  Necesitamos accesos a memoriaató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 Arquitecturas Paralelas 12-13

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 - Buena escalabilidad - Bajo coste de memoria - Igualdad de oportunidades Arquitecturas Paralelas 12-13

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 -funcioneslock - 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. Arquitecturas Paralelas 12-13

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

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 Arquitecturas Paralelas 12-13

T&S - Swap 1.2Swap ▪SWAP R1,S R1 <--> MEM[S]; lock: ADDI R1,R0,#1 l1: SWAP R1,S BNZ R1,l1 RET unlock: ST S,R0 RET Arquitecturas Paralelas 12-13

T&S - Swap Tráfico En sistemas SMP es muy importante mantener el tráfico limitado. La instrucción T&Sescribe 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. Arquitecturas Paralelas 12-13

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

T&S with backoff  Mejoras para minimizar el tráfico 1Test&Set with backoff 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: t0 = k; t1 = k × c; t2 = k × c2; ... (c>1) Arquitecturas Paralelas 12-13

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). lock: LD R1,S BNZ R1,lock T&S R1,S BNZ R1,lock RET Arquitecturas Paralelas 12-13

P0 P1LD P2LD P3LD P4LD SC x x x x x LD[TS....... BRQ LD...... TS/INV]LD.. x BRQ..... LD[TS....... BRQ... x BRQ x BRQ........ TS/INV]LD.. x BRQ. LD... BRQ....... LD[TS... TS/INV]LD......... x BRQ............... BRQ........... LD[TS. Test-and-T&S: simulación de tráfico S=0,INV • 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 – 2 P proc. → 3P2/2 TS/INV] Arquitecturas Paralelas 12-13

LL – SC / C&Swap 2.1Load Locked / Store Conditional - La operación atómica se divide en dos partes - Para asegurar la atomicidad se utiliza un flag de hardware ▪LL R1,S R1 := MEM[S]; LSin [dir] := S; LSin [flag] := 1; ▪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 Arquitecturas Paralelas 12-13

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

SC x x x x BRQ LL(1)[SC..... SC /INV] SC] LL............ LL(1)[SC...... (0)x BRQ BRQ..... SC] LL....... BRQ........ LL(1)[SC.. (0)x BRQ.... SC]LL..... LL(1)[SC (0)xBRQ........ BRQ............ LL- SC: simulación del tráfico P0 P1LL P2LL P3LL P4LL S=0,INV Tráfico de datos (bloques) para que entre un proc. en SC → P + (P – 1) para salir de SC → 0 en total → 2P – 1 P proc. → P2 Arquitecturas Paralelas 12-13

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 Arquitecturas Paralelas 12-13

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; Arquitecturas Paralelas 12-13

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

Tickets  Alternativas para reducir el tráfico 1Tickets 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 Arquitecturas Paralelas 12-13

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

Vectores de cerrojos  Alternativas para reducir el tráfico 2Vectores 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 Arquitecturas Paralelas 12-13

P0 P1LD.. P2LD.... P3LD.... P4LD.... SC SC x x x x LD x BRQ LD BRQ LD....... BRQ..... LD... BRQ......... LD... BRQ............ Tickets / Vectores de cerrojos: simulación del tráfico P0 P1LD P2LD P3LD P4LD TURNO++,INV VC(I+1)=0,INV • Tráfico de datos (bloques) • Tickets → 1 + P → P(P+3) / 2 • Vectores de cerrojos → 1 + 1 + 1 → 3P Arquitecturas Paralelas 12-13

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 (sin límite) Test-and-Test&Set P(3P-1)/2 70 bloques LL - SC P2 49 bloques Tickets P(P+3)/2 35 bloques Vector de cerrojos 3P 21 bloques

while (flag == 0); flag = 1; Sincronización mediante eventos • 1Sincronizació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); post(flag,i); wait(flag,i); Arquitecturas Paralelas 12-13

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

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); } Arquitecturas Paralelas 12-13

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); } Arquitecturas Paralelas 12-13

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) Arquitecturas Paralelas 12-13

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... Arquitecturas Paralelas 12-13

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. Arquitecturas Paralelas 12-13

4. Sincronización de procesos en sistemas SMP