Gestión de Procesos1 Horas 1INTRODUCCIÓN4 2PROCESOS Y THREADS10 3GESTIÓN DE MEMORIA8 4ENTRADA / SALIDA2 5SISTEMA DE FICHEROS6 sisOpeTemarioCurso: 14/15.

Presentación del tema: "Gestión de Procesos1 Horas 1INTRODUCCIÓN4 2PROCESOS Y THREADS10 3GESTIÓN DE MEMORIA8 4ENTRADA / SALIDA2 5SISTEMA DE FICHEROS6 sisOpeTemarioCurso: 14/15."— Transcripción de la presentación:

1 Gestión de Procesos1 Horas 1INTRODUCCIÓN4 2PROCESOS Y THREADS10 3GESTIÓN DE MEMORIA8 4ENTRADA / SALIDA2 5SISTEMA DE FICHEROS6 sisOpeTemarioCurso: 14/15

2 Gestión de Procesos2 sisOpe2. Procesos y ThreadsCurso: 14/15 Introducción Procesos Visión abstracta Esbozo de implementación Threads (Procesos ligeros) Comunicación entre procesos Condición de carrera Exclusión mutua y región crítica Implementación de la exclusión mutua Paso de mensajes Planificación de procesos Criterios Políticas Sistemas multiprocesador

3 Gestión de Procesos3 INTRODUCCIÓN Interesa tener máquinas que ejecuten varios procesos al mismo tiempo 18 T1T1 T2T2 T3T3 t Aprovechar tiempos muertos E/S Soluciones elegantes concurrentes Más rapidez con más de una CPU T1T1 T2T2 T3T3 t 13 CPU1 CPU2 Con multiprocesadores también interesa multiplexar las CPU’s pseudoparalelismo

4 Gestión de Procesos4 PROCESOS (Visión abstracta: Recordar sus llamadas) Dos relaciones típicas entre proceso Padre y proceso Hijo: 1.Procesos independientes: La “shell” crea un proceso para ejecutar un programa de usuario “ls” ls.exe shell P a.Debe cargarse el ejecutable en memoria ls b.Dotarle de registros, pila, etc. H a.El código ya está en memoria 2.Procesos cooperantes: Un servidor Web crea un proceso para atender una petición de un cliente web P b.Dotarle de registros, pila, etc. H Parecido a Threads ¿fork + exec? ¿fork?

5 Gestión de Procesos5 PROCESOS (Visión abstracta: Recordar sus llamadas) Proceso de arranque y grupos de procesos P1 P2P3 P4 P5 P6 P7 init id:rlevel:action:process /etc/inittab xinetd /etc/rc5.d /etc/rc.d/rc 5 login login as: Password: bash pcarazo:........:/bin/bash /etc/passwd PC1> grupo de procesos Red putty ? gdm 0 Halt 1 Monousuario 2 MultiSinRed 3 MultiConRed 5 X11 6 Reboot rlevel

6 Gestión de Procesos6 PROCESOS (Visión abstracta: Recordar sus llamadas)

7 Gestión de Procesos7 Esbozo de implementación ¿Cómo es el ciclo de vida de un proceso? CPU Creación P1 P2 P3 P1 ¿P1.read(disco, )?¿P2.sleep(5 )? P2 P3 P2 P3 P4 ¿P3 mucha CPU? Expulsión P3 P4 P3 ¿P1 fin E/S? P1 ¿P4 read(cinta, ) P4 P3 P1 ¿P3 termina? Terminación P1 P2P4 ¿Estados de un proceso? EnEjecución Preparado EnEspera o Bloqueado Activo Ejecu. Prep.Espera

8 Gestión de Procesos8 Diagrama de transición de estados de un Proceso PreparadoEnEjecuciónEnEspera fork h fork p exit wait sleep F.R. ¿fork p ? ¿fork h ?

9 Gestión de Procesos9 El contexto de un proceso está distribuido en varias zonas CPU MP MSec S.O. Esbozo de implementación en términos más informáticos Contexto de memoria (Código y Datos)MP/MSec Bloque de control (descriptor) del ProcesoMP (S.O.) Contexto del procesador Reg/MP/MSec Ejecutándose Bloqueado pila

10 Gestión de Procesos10 Esbozo de implementación ( ¿Cuántos procesos? ) ¿#Procesos ilimitado o un máximo predeterminado? maxProcesos: constant:=100; type idProceso is NATURAL range 0..maxProcesos; Reservado procesos : array[1..maxProcesos] of descriptorProceso; 1234979899100 50 type descriptorProceso is record pid: ----------; --------------- end record; 584 ejecutandose : idProceso; ¿Correcto?

11 Gestión de Procesos11 Esbozo de implementación ( ¿Cómo dar los PID’s? ) type descriptorProceso is record pid: idProceso; --------------- end record; 1234979899100 50 1..100 ¿Problemas? 99 procesos en el sistema Hago ps y veo un proceso mío (57) Me dispongo a kill –9 57 Mi proceso termina antes del kill y se crea otro proceso con el código 57 ¡ Mato a otro proceso ! Mejor espaciar más los códigos pid: NATURAL;1..65535...Algo más complejo dar PID’s 0  Descriptor libre ¿ejecutandose?

12 Gestión de Procesos12 Esbozo de implementación ( ¿Estados y su gestión? ) type unEstado is (ejecutandose, preparado, espLapso, espFinHijo, zombie);

13 Gestión de Procesos13 Esbozo de implementación ( ¿Estados y su gestión? ) type unEstado is (ejecutandose, preparado, espLapso, espFinHijo, zombie); type descriptorProceso is record pid: NATURAL; estado: unEstado; end record; 1234979899100 50 CPU queda libre. ¿A qué Pi se la doy? Recorro procesos buscando uno que esté preparado Lento e injusto Si decido elegir al Pi que lleva más tiempo preparado, lo mejor cola FIFO type unaCola is record primero: idProceso := 0; ultimo: idProceso:= 0; end record; preparados: unaCola; sig: IdProceso; ejecutandose: idProceso;

14 Gestión de Procesos14 Esbozo de implementación ( ¿Procesos bloqueados? ) espLapso => Muy parecido a preparados, sólo que es necesario indicar cuándo despertarles o cuánto falta para despertarles,... 1234979899100 50 type descriptorProceso is record pid: NATURAL; estado: unEstado; sig: idProceso; lapso: NATURAL; end record; espLapso : unaCola; 10525 El campo sig me sigue sirviendo para encadenar Otras formas de implementarlo: 5515 45097

15 Gestión de Procesos15 Esbozo de implementación ( ¿Procesos bloqueados? ) espFinHijo => El fin de un hijo sólo puede estar esperándolo su Padre. Puede no ser necesaria una cola. type descriptorProceso is record pid: NATURAL; padre: idProceso; estado: unEstado; sig: idProceso; lapso: NATURAL; end record; El Padre (P) hace wait (H): -- Localizar H en procesos => h if h.estado = zombie then Liberar recursos del Hijo y continuar al Padre else -- hijo vivo p.estado:=espFinHijo; p.sig:=h; liberar CPU; Un Hijo(H) termina exit: If (p.estado = espFinHijo) & (p.sig = h) then liberar recursos Hijo y continuar Padre else h.estado := zombie y liberar CPU

16 Gestión de Procesos16 Esbozo de implementación ( Concluyendo ) maxProcesos : constant := 100; type idProceso is NATURAL range 0..maxProcesos; type unEstado is (ejecutandose, preparado, espLapso, espFinHijo, zombie); type descriptorProceso is record pid: NATURAL; padre: idProceso; estado: unEstado; sig: idProceso; lapso: NATURAL; SP: address; memoria: ----------; ficheros: ----------; tiempos: ----------; end record; type unaCola is record primero: idProceso := 0; ultimo: idProceso := 0; end record; procesos : array [1..maxProcesos] of descriptorProceso; ejecutandose: idProceso; preparados, espLapso: unaCola; ¿ fork y exec ?

17 Gestión de Procesos17 Campos en una entrada a la tabla de procesos Esbozo de implementación ( Otro ejemplo )

18 Gestión de Procesos18 Esbozo de implementación ( El Cambio de Contexto ) Causas? Llamada al Sistema Fin de Proceso Bien/Mal Interrupción Trap (E/S, F.R.) Mecanismo similar Supongamos como causa “Fin de Rodaja” ejecu- tándose Pi Hw (1) (1)Reconocimiento de la interrupción S.O. Pj Ens. (2) (2)Salvar reg (Pi) y conmutar de pila C/Modula/Ada (3) (3)1Recorrer dormitorio 2Elegir siguiente proceso Ens. (4) (4)Recuperar reg (Pj) y cederle control Planificador Dispatcher ¿No hay procesos preparados?

19 Gestión de Procesos19 Vector de Interrupciones S.O. Esbozo de implementación ( El Cambio de Contexto ) ---------- sleep(10) ---------- exit(0) ------- TRAP #0 ------- INT 3 ---------- divu d5,d0 ---------- ------- DIV 0 Se salva el SR y PC ------- Cambio de contexto

20 Gestión de Procesos20 Threads ( Visión abstracta ) Modelo de procesos más común  Espacios de direcciones disjuntos Registros Código Datos, Pila Ficheros Pi Registros Código Datos, Pila Ficheros Pj forkexec ls.exe Facilita protección Pi  Pj, pero: Creación laboriosa Cambio de contexto pesado (procesador + entorno) TLB’s, cachés,... Comunicación vía mensajes más seguro pero más lento ¿Y si los procesos son cooperantes? Objetivo común Colaboración vs agresión Protección más laxa Pueden desear mantener datos comunes con los menores costes de tiempo

21 Gestión de Procesos21 BD utilidades Threads ( Visión abstracta ) Procesos Ligeros  Espacios de direcciones no disjuntos Registros Pila Registros Pila Código, Datos Ficheros TiTjServidor de localización de utilidades C1C1 C2C2 CnCn S consulta alta consulta petición respuesta petición ¡ Muy eficaz con multiprocesadores ! Soportados de dos formas: En el espacio del S.O. En el espacio del Usuario Biblioteca

22 Gestión de Procesos22 Threads ( “Linux” ) int __clone (int (*fn) (void *arg), void *child_stack, int flags, void *arg) Como fork sólo que crea un Thread “Específico de Linux” Thread soportado como tal por el S.O. (no portable) Biblioteca pthread (API POSIX 1003.1c) int pthread_create (pthread_t * thread, atributos, funcion, argumentos) pthread_t pthread_self (void) int pthread_exit (void *estado) int pthread_join (pthread_t thread, void **estado)................................................... ¿ fork + threads ?

23 Gestión de Procesos23 Threads ( Ejemplos de uso: tonto.c ) #include int main (int argc, char *argv[]){ pthread_t tA, tB; int datoA=0; datoB=0; pthread_create(&tA, NULL, A, NULL); pthread_create(&tB, NULL, B, NULL); pthread_join (tA, NULL); pthread_join (tB, NULL); exit (0); } void *B (void *basura) { datoB = 2000; sleep (5); printf (“datoA=%d\n”, datoA); pthread_exit (NULL); } void *A (void *basura) { datoA = 1000; sleep (5); printf (“datoB=%d\n”, datoB); pthread_exit (NULL); } datoC=0; int datoC; ?

24 Threads ( Ejemplos de uso: cuentaPar.c ) cuentaPar.c: Número de apariciones de un número en un vector 6 2 0 7 4 9 3 4 9 8 0 6 7 9 6 0 6 7 9 8 6 2 5 2 6 4 7 9 3 5 2 1 7 3 2 6 6 4 4 0 const N = 40; objetivo = 6; numCPUs = 4; var vector array[1..N] of integer; ¿ Algoritmo paralelo ? T0T0 T1T1 T2T2 T3T3 1322 + 8 Gestión de Procesos24

25 int longRodaja, numVecesLocal[MAX_ESCLAVOS], *vector; void *esclavo (void *parametro) {..... } int main (int argc, char *argv[]) { int i, numVeces, cardinalidad = atoi (argv[1]); int numEsclavos = atoi (argv[2]); pthread_t pids[MAX_ESCLAVOS]; // Pedir memoria e inicializar vector // Crear esclavos y esperar a que terminen su trabajo for (i = 0; i < numEsclavos; i++) pthread_create (&pids[i], NULL, esclavo, (void *) i); for (i = 0; i < numEsclavos; i++) pthread_join (pids[i], NULL); // Sumar los valores de todos e informar del resultado numVeces = numVecesLocal[0]; for (i = 1; i < numEsclavos; i++) numVeces = numVeces + numVecesLocal[i]; printf (“Veces que aparece = %d\n”, numVeces); } %cuentaPar 1000000 4 Threads ( Ejemplos de uso: cuentaPar.c ) 25 Gestión de Procesos

26 // Variables globales int longRodaja, numVecesLocal[MAX_ESCLAVOS], *vector; void *esclavo (void *parametro) { int yo, inicio, fin, i, j, numVeces; yo = (int) parametro; inicio = yo * longRodaja; fin = inicio + longRodaja; // Buscar en mi parte del vector numVeces = 0; for (i = inicio, i < fin; i++) if (vector[i] == NUM_BUSCADO) numVeces++; numVecesLocal[yo] = numVeces; pthread_exit (NULL); } Gestión de Procesos26 Threads ( Ejemplos de uso: cuentaPar.c )

27 51,2864,260,85 61,1274,860,81 71,1134,920,70 80,9985,490,69 cuentaPar 400.000.000 1..8 // Recorriéndolo diez veces 2 Xeon E5520 Quad 2,26GHz 8ML3 12GB 500GB Threads ( Ejemplos de uso: cuentaPar.c ) Gestión de Procesos27 EsclavosTiempoAceleraciónEficiencia 15,480 22,7212,011,01 41,4083,890,97 A n = T 1 / T n E n = A n / n

28 sortPar.c: Ordenar un vector en memoria 3 8 15 2 4 1 7 10 6 14 13 5 11 9 12 16 T0T0 T1T1 T2T2 T3T3 2 3 8 15 1 4 7 10 5 6 13 14 9 11 12 16 ordenar 1 2 3 4 7 8 10 15 5 6 9 11 12 13 14 16 T0T0 T2T2 mezclar T0T0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 mezclar Threads ( Ejemplos de uso: sortPar.c ) Gestión de Procesos28

29 sortPar.c: Ordenar un vector en memoria [Refinamiento] ABCD EF G 0123 02 0 esclavo (yo: integer); ordenarRodaja(yo); case yo of 0: mezclar(A,B,E); mezclar(E,F,G); 1: ; 2: mezclar(C,D,F); 3: ; end; ? 1.La mezcla es destructiva => vector auxiliar Va Vb Va 2Mezclar requiere haber ordenado … => semáforos Threads ( Ejemplos de uso: sortPar.c ) Gestión de Procesos29 sem_init sem_wait sem_post

30 #define MAX_ENTERO 10000 #define MAX_ESCLAVOS 4 // Solo funciona con 4 esclavos //-------------- VARIABLES GLOBALES ------------------------------- int cardinalidad, longRodaja; int *vector, *vectorBis; sem_t S1a0, S3a2, S2a0; void imprimir (int *vector) { int i; printf ("Contenido del vector\n"); printf ("====================\n"); for (i=0; i<cardinalidad; i++) { printf ("%6d ", vector[i]); if ((i%10) == 0) printf ("\n"); } printf ("\n"); } void mezclar (int i, int longRodaja, int *vOrg, int *vDst) { int iDst, iTope, j, jTope; iTope = i + longRodaja; j = iTope; jTope = j + longRodaja; for (iDst = i; iDst < jTope; iDst++) { if (i == iTope ) vDst[iDst] = vOrg[j++]; else if (j == jTope ) vDst[iDst] = vOrg[i++]; else if (vOrg[i] < vOrg[j]) vDst[iDst] = vOrg[i++]; else vDst[iDst] = vOrg[j++]; } Threads ( Ejemplos de uso: sortPar.c ) Gestión de Procesos30

31 void *esclavo(void *parametro) { int yo, inicio, fin, i, j, imenor, menor; int unCuarto, unMedio; yo = (int) parametro; inicio = yo * longRodaja; fin = inicio + longRodaja; unMedio = cardinalidad / 2; unCuarto = cardinalidad / 4; // Ordenar por insercion directa for (i = inicio; i < fin; i++) { imenor = i; menor = vector[i]; for (j = i; j < fin; j++) if (vector[j] < menor) { imenor = j; menor = vector[j]; } vector[imenor] = vector[i]; vector[i] = menor; } // Fase de mezclas. Solo valida para 4 esclavos switch (yo) { case 0: sem_wait (&S1a0); mezclar(0, unCuarto, vector, vectorBis); sem_wait (&S2a0); mezclar(0, unMedio, vectorBis, vector); break; case 1: sem_post (&S1a0); break; case 2: sem_wait (&S3a2); mezclar(unMedio, unCuarto, vector, vectorBis); sem_post (&S2a0); break; case 3: sem_post (&S3a2); break; default: printf ("Error\n"); break; } pthread_exit(NULL); } Threads ( Ejemplos de uso: sortPar.c ) Gestión de Procesos31

32 int main( int argc, char *argv[] ) { int i, numEsclavos; pthread_t pids[MAX_ESCLAVOS]; cardinalidad = atoi(argv[1]); numEsclavos = MAX_ESCLAVOS; longRodaja = cardinalidad / numEsclavos; // Pedir memoria e inicializar el vector vector = malloc(cardinalidad * sizeof(int)); vectorBis = malloc(cardinalidad * sizeof(int)); for (i=0; i<cardinalidad; i++) vector[i] = random() % MAX_ENTERO; imprimir(vector); // Inicializar semaforos para sincronizar sem_init (&S1a0, 0, 0); sem_init (&S3a2, 0, 0); sem_init (&S2a0, 0, 0); // Crear esclavos y esperar a que terminen su trabajo for (i=0; i<numEsclavos; i++) pthread_create (&pids[i], NULL, esclavo, (void *) i); for (i=0; i<numEsclavos; i++) pthread_join (pids[i], NULL); imprimir(vector); return (0); } sort 200000 => 8:350 sortPar 200000 => 2:100 Threads ( Ejemplos de uso: sortPar.c ) Gestión de Procesos32

33 Gestión de Procesos33 pthread_create pthread_join pthread_exit pthread_self Threads ( En el espacio de usuario ) El S.O. no los soporta Cambio contexto rápido Distintos planificadores read, … ¡ Bloqueantes ! Falta de página ¡Planificación expulsora!

34 Gestión de Procesos34 Threads ( En el espacio del S.O. ) ?

35 Gestión de Procesos35 Comunicación entre Procesos Los procesos cooperantes necesitan mecanismos para sincronizarse y comunicarse información de forma segura Sincronización  Ordenación temporal de la ejecución de procesos A antes que B Canal de PanamáTortilla de patatas BatirPelarPelar HuevosCebollasPatatas Mezclar, Añadir Sal y Freir Comunicación  Paso de información entre tareas Síncrona o Asíncrona Filtros Unix: who | wc | sed -e ‘s/ [ ]*/:/g’ | cut -d: -f2

36 Gestión de Procesos36 Condiciones de Carrera La falta de sincronismo entre procesos cooperantes da problemas Canal de Panamá  Barco encallado Tortilla de Patatas  No hay quien se la coma Uso de datos / recursos comunes  Inconsistencia ¡Que buen negocio! ¡Me tangan!

37 Gestión de Procesos37 Condiciones de Carrera (Modelización con threads) Ingreso de Taxista 1 = 80729 Ingreso de Taxista 2 = 80618 Total recaudacion = 161096 + 161347 int cuenta; void *taxista(void *parametro) {..... } int main( int argc, char *argv[] ) { int i, numEsclavos; pthread_t pids[MAX_ESCLAVOS]; numEsclavos = atoi(argv[1]); cuenta = 0; // Crear esclavos y esperar a que terminen su trabajo for (i=0; i<numEsclavos; i++) pthread_create (&pids[i], NULL, taxista, (void *) i); for (i=0; i<numEsclavos; i++) pthread_join (pids[i], NULL); printf ("Total recaudacion = %d\n", cuenta); return (0); }

38 Gestión de Procesos38 Ingreso Condiciones de Carrera (Modelización con threads) void *taxista (void *parametro) { // Variables recaudacion = 0; mio = 0; do { espera = random() % MAX_ESPERA; for (i=1; i<espera; i++); importe := random (maxImporte); mio := mio + (importe / RATIO_TAXISTA); cuenta := cuenta + importe – (importe / RATIO_TAXISTA); recaudacion := recaudacion + importe; } while (mio < SUELDO_DIA); printf (“Ingreso de Taxista %d = %d\n”, yo, recaudacion – mio); pthread_exit (NULL); } Hacer Carrera Buscar Cliente

39 Gestión de Procesos39 Condiciones de Carrera (Modelización con threads) Threadspc1:4Corespc9:8Cores 2 4 8 16 32 Fallos x 1.000 7 64 230 533 830 207 926 1.000

40 Gestión de Procesos40 3: cuenta := cuenta + importe Condiciones de Carrera (El problema) 3.1: PUSH importe 3.2: PUSH cuenta 3.3: ADDP 3.4: POP cuenta 3.1, 3.2 T1 T2 5.000 cuenta 10.000 T1.importe 3.3 5.000 10.000 T1.SP 3.1, 3.2 1.500 T2.importe 3.3 5.000 1.500 T2.SP 3.3, 3.4 15.000 cuenta 3.3, 3.4 6.500 cuenta 6.500 ¿problema?

41 Gestión de Procesos41 Exclusión mutua y Región crítica (La solución) RC Aquí como máximo un Pi Exclusión Mutua Integridad Datos Comunes Aquí cero, uno o más Pi Los Pi indicarán cuándo EntranEnRC y cuándo SalenDeRC

42 Gestión de Procesos42 Exclusión mutua y Región crítica (La solución) EntrarEnRC; cuenta := cuenta + importe – (importe div ratioTaxista); SalirDeRC; REQUISITOS En una misma Región Crítica no más de un proceso Sin supuestos: #µP, #Pi, velocidades relativas,..... Ningún Pi fuera de su Región Crítica bloqueará a otros Pj Decisión de quién entra a una Región Crítica en un tiempo finito

43 Gestión de Procesos43 Implementación de la Exclusión Mutua Mecanismos: Inhibición de interrupcionesSemáforos Cerrojos (espera activa)Monitores HwSw Lenguaje S.O. Inhibición de interrupciones Taxistas InhibirInterrupciones cuenta := cuenta + importe PermitirInterrupciones  RC muy corta o pueden perderse interrupciones  Exclusión total vs parcial DirecciónGeneralDeTráfico repeat aguardarAgazapados y ¡foto! InhibirInterrupciones numeroMultas++ PermitirInterrupciones until cubiertoCupo  Sólo válido en monoprocesador  Peligroso en manos del usuario  Útil dentro del propio S.O.

44 Gestión de Procesos44 Implementación de la Exclusión Mutua ( Cerrojos ) Una variable “cerrojo” por cada RC distinta que indica Libre/Ocupada Taxistas Entrar (RCTaxistas) cuenta := cuenta + importe Salir (RCTaxistas) Guardia Civil Entrar (RCDGT) numeroMultas++ Salir (RCDGT) while RCT = ocupada do null; RCT := ocupada cuenta := cuenta + importe; RCT := libre entrartst.bRCT bnzentrar move.b#$FF,RCT pushimporte pushcuenta addp popcuenta salirmove.b#$00,RCT RCTdc.b0 ¡ No funciona !

45 Gestión de Procesos45 Implementación de la Exclusión Mutua ( El cerrojo falla ) T1 T2 00 RCT ---------------- entrartst.bRCT ---------------- tst.bRCT bnzentrar move.b#$FF,RCT ---------------- T1.SR Z 1 FF RCT T2 dentro RCT bnzentrar move.b#$FF,RCT ---------------- FF RCT ¡¡ T1 también dentro RCT !!

46 Gestión de Procesos46 Implementación de la Exclusión Mutua ( Un cerrojo seguro? ) El Hw ayuda con una instrucción atómica que consulta y cambia valor tas.bcerrojo, valor tst.bcerrojo move.bvalor,cerrojo Algoritmos: Dekker, Dijkstra, Knuth, Peterson,....... entrartas.bRCT,#$FF bnzentrar pushimporte pushcuenta addp popcuenta salirmove.b#$00,RCT RCTdc.b0 F.R.¿Habrá problemas? No funciona en multiprocesador ya que TAS es ininterrumpible dentro de un procesador, pero supone dos accesos al bus: 1Lectura del cerrojo 2Modificación del cerrojo ¡SI!

47 Gestión de Procesos47 Implementación de la Exclusión Mutua ( Un cerrojo seguro! ) T1 T2 00 RCT ---------------- tas.bRCT,#$FF ---------------- tas.bRCT,#$FF bnzentrar T1.SR Z 1 FF RCT FF RCT bnzentrar ------------- T1 en RCT FF RCT T2 no puede entrar en RC mientras está T1 tas.bRCT,#$FF bnzentrar

48 Gestión de Procesos48 Implementación de la Exclusión Mutua ( TAS todavía falla! ) TAS  PedirBus, Leer, PedirBus, Escribir  P1  T1PB, L1, PB, E1  P2  T2PB, L2, PB, E2 ???  P1  P2 RCT L1, E1, L2, E2 T1 T2 L2, E2, L1, E1 T2 T1 L1, L2, E1, E2 T1 T2 tas.bRCT,#$FF bnzentrar PHPH tasl.bRCT,#$FF bnzentrar --------------------- ¡ Todavía dos problemas ! Espera Activa Inversión de prioridades PLPL deadLock ¿ Qué hacer ? TASL “TAS with Lock”  BusLock, Leer, Escribir, BusRelease ( El Hw nos ayuda )

49 Gestión de Procesos49 Implementación de la Exclusión Mutua ( RC POSIX ) int pthread_mutex_lock (pthread_mutex_t *regionCritica) int pthread_mutex_unlock(pthread_mutex_t *regionCritica) ¿Posible implementación (sin espera activa)? type pthread_mutext_t is record libre : BOOLEAN; cola : unaCola; end record; F RCTPiPj lock (RCT): inhibir interrupciones salvarEstado(ejecutandose) if RCT.libre then RCT.libre = FALSE elsemeter (ejecutandose, RCT); ejecutandose = planificar(); recuperarEstado(ejecutandose) rte /*Se habilitan interrupciones*/ Multiprocesador ? tasl ¡ Ojo !

50 Gestión de Procesos50 Implementación de la Exclusión Mutua ( Semáforos ) Soportado por el S.O. garantiza exclusión mutua sin espera activa type Semaforos is private; Inicializar (S: Semaforos; Valor: NATURAL); Bajar (S);-- Puede bloquear al proceso (Si Valor = 0) Subir (S);-- Puede desbloquear a UN proceso Operaciones Atómicas Dar soporte a RC con semáforos es fácil: Inicializar (S_RCT, 1)Inicializar (S_RCGC, 1) --------------- Bajar (S_RCT)Bajar (S_RCGC) Cuenta := Cuenta + ImportenumeroMultas++ Subir (S_RCT)Subir (S_RCGC)---------------

51 Gestión de Procesos51 Implementación de la Exclusión Mutua ( Semáforos ) Precisando la semántica: P.Bajar (S)  IF Valor(S) > 0 THEN Valor (P.Bajar(S)) = Valor(S) – 1 ELSE P deja UCP y se bloquea esperando P’.Subir(S) P.Subir(S)  IF Hay_algun_Pi_esperando_en (S) THEN Sacar a uno de ellos de espera INDETERMINISMO Proceso continuado Proceso que coge UCP JUSTICIA ELSE Valor (P.Subir(S)) = Valor (S) + 1

52 Gestión de Procesos52 Implementación de la Exclusión Mutua ( Semáforos ) private type Semaforos is record valor : NATURAL; cola : unaCola; end record; procedure Inicializar (S: out Semaforos; valor: NATURAL) is begin S.valor := valor; end Inicializar; Esbozo de implementación: 0 SPiPkPj ¿Dónde están los semáforos? Hacen falta operaciones del estilo: crear, conectarse, destruir Exclusión mutua, Salvado estado Pi Dispatcher

53 Gestión de Procesos53 Implementación de la Exclusión Mutua ( Semáforos ) procedure Bajar (S: in out Semaforos) is begin if S.valor = 0 then encolar (ejecutandose, S.cola); planificar; else S.valor := S.valor - 1; endif; end Bajar; procedure Subir (S: in out Semaforos) is begin if S.cola.primero /= 0 then encolar (sacarProceso(S.cola), preparados); planificar; else S.valor := S.valor + 1; endif; end Subir;

54 Gestión de Procesos54 Implementación de la Exclusión Mutua ( Semáforos POSIX ) int sem_init(sem_t *S, int global, unsigned int valor) int sem_wait(sem_t *S) int sem_post(sem_t *S) int sem_destroy (sem_t *S)

55 Gestión de Procesos55 Paso de mensajes Debilidades del Sincronismo + Memoria Común: Primitivas de bajo nivel (Inhibir Interrupciones, TASL, Semáforos) Inviable en sistemas débilmente acoplados sin memoria común Solución: Envío y recepción de mensajes P org P dst Enviar (P dst, msj)Recibir (P org, msj) ----- Escribe 11 ----- 11 Lee Primera aproximación a la sintaxis: void enviar (int Pdestino,void recibir (int Porigen, char * msj);char * msj); ¿Puede fallar enviar/recibir? ? ? int

56 Paso de mensajes ( Ejemplos de uso: cuentaParMsj.c ) ¿Cómo podría ser cuentaPar.c si no hay memoria común? 1322 6 2 0 …0 6 7 …6 2 5 …2 1 7 … + 8 esclavo1esclavo2esclavo3esclavo4 maestro 6 2 0 …0 6 7 …6 2 5 …2 1 7 … El vector lo tiene un proceso “maestro” El maestro:reparte “envía” trabajo a los “esclavos” y recoge “recibe” resultados 6 2 0 …0 6 7 …6 2 5 …2 1 7 … 1 32 2 Gestión de Procesos56

57 Gestión de Procesos57 Paso de mensajes ( Ejemplos de uso: cuentaParMsj.c ) #define longRodaja (N/4) int vector[N], iRodaja; int veces, vecesLocal; // Repartir trabajo iRodaja = 0; for e in 1..4 { enviar (e, &vector[iRodaja], longRodaja); iRodaja += longRodaja; } // Recoger resultados veces = 0; for e in 1..4 { recibir (e, &vecesLocal, 1); veces += vecesLocal; } #define longRodaja (N/4) int rodaja[longRodaja]; int veces; recibir (0, rodaja, longRodaja); veces = contarEn (rodaja); enviar (0, &veces, 1); maestro esclavo

58 Gestión de Procesos58 Paso de mensajes (muchas semánticas) ----- rec (Po, msj) ----- env (Pd, msj) ----- Pd¿Bloqueo? El bloqueo dependerá de la  |  de mensajes  msj  Se le entrega a Pd y continua  msj  Se bloquea a Pd hasta No siempre Tiempo Real Tolerancia a Fallos Bloquear Bloquear un máximo No Bloquear int recibir (int Porg, char * msj, int TmaxEsp)  7 0 ? ? Po ¿Bloqueo? ¿Recibió Pd? Po Independencia del enlace de comunicación

59 Gestión de Procesos59 Paso de mensajes (Cuestiones de Diseño) Mensajes de longitud fija vs variable Capacidad de almacenamiento0..  Envío por copia vs referencia Comunicación Directa vs Indirecta Pi B PjPi Pj Simétrica vs Asimétrica Unidireccional vs Bidireccional

60 Gestión de Procesos60 Paso de mensajes (Mensajes de longitud fija vs variable) Longitud Fija El S.O. siempre envía el total La aplicación distingue distintos msj. Simplifica la gestión de la capacidad de almacenamiento del canal Longitud Variable El S.O. envía lo que diga la aplicación ¿Cómo? 110 Mensaje de 110 bytes En el propio mensaje enviar (Pdest, msj, 110) En la llamada

61 61 Paso de mensajes (Mensajes de longitud fija vs variable) MINIX 3 typedef struct { int m_source; int m_type; union { mess_1 m_m1; mess_2 m_m2; mess_3 m_m3; mess_4 m_m4; mess_5 m_m5; mess_7 m_m7; mess_8 m_m8; } m_u; } message; m_source m_type m1_i1 m1_i2 m1_i3 m1_p1 m1_p2 m1_p3 m_source m_type m2_i1 m2_i2 m2_i3 m2_l1 m2_l2 m2_p1 m_source m_type m3_i1 m3_i2 m3_p1 m3_ca1 m_source m_type m4_i1 m4_i2 m4_i3 m4_i4 m4_i5 Práctica 4: Nueva llamada SO Proceso70.if (proceso_vivo(84) 70 57 84 # Llamada 57

62 Gestión de Procesos62 Paso de mensajes (Capacidad de almacenamiento 0..  ) Ilimitada (  ) PoPd PoPd ¡Nunca Bloqueo! Limitada ( 8 ) PoPd PoPd Hueco  Sin Bloqueo ¡No hay Hueco! Bloqueo Sin Bloqueo Estado = Lleno Comunicación Asíncrona Nula ( 0 ) PoPd ¡Siempre Bloqueo! PoPd Espera a Pd.recibir PoPd Cita “Rendez-vous” PoPd Comunicación Síncrona Po sabe que Pd recibió ¿Y aquí?

63 Gestión de Procesos63 PoPd Paso de mensajes (Envío por copia vs referencia) Escribir ----- env (Pd, msj) 1 rec (Po, msj) 2 ¡ 2 copias extra por cada envío/recepción ! Leer ----- Envío por referencia PoPd pedirBuffer Escribir ----- env (Pd, msj) rec (Po, msj) Leer ----- liberarBuffer Complejidad pedir/liberar Buffer ¿Y si no hay memoria común? ¿Seguridad?

64 Gestión de Procesos64 Paso de mensajes (Comunicación Directa) Indicación explícita A qué proceso se desea enviar De qué proceso se desea recibir ClienteServidor ¿15.731 es primo? SÍrepeat read (msjp.num);recibir (Pc, &msjp); enviar (Ps, &msjp);enviar (Pc, recibir (Ps, &msjr);respuesta(msjp)) imprimir (msjr.esPrimo)forever forever Simétrica

65 Gestión de Procesos65 Paso de mensajes (Comunicación Directa “Características”) Creación automática del enlace PoPd Necesidad de conocer los Pid’s de los procesos De Pi a Pj SÓLO un enlace en cada sentido ClienteServidor esPrimo? Hora? ClienteServidor ? 15.731 0 1 Tipo de mensaje ¿Todo resuelto? ClienteServidor PPPPPPPH Un enlace asocia SÓLO a dos procesos

66 Gestión de Procesos66 Paso de mensajes (Un enlace asocia SÓLO a dos procesos) C1 C2 S C1 C2 S repeat ifrecibir (PC1, &msjp ) then enviar (PC1, respuesta (msjp)); elsifrecibir (PC2, &msjp ) then enviar (PC2, respuesta (msjp)); forever Servidor Inanición Espera Activa, 1 Mitigada? 50 Clientes???? ! Demasiadas pegas ¡

67 Gestión de Procesos67 Paso de mensajes (Comunicación Directa Asimétrica) Mejor admitir un recibir de cualquier proceso (no uno concreto) C1 C2 S int recibir (char * msj) Pid del proceso remitente int recibir (int * remitente, char * msj) equivalentes repeat remitente := recibir (&msjp); enviar (remitente, respuesta (msjp)); forever Servidor ¿Más de un servidor? int enviar (char * msj) Pid del proceso que recibió??? C S1 S2

68 Gestión de Procesos68 Paso de mensajes (Comunicación Indirecta) bPeti PCPS 1  1 bPeti PC PS 1 PS m 1  M bPeti PC 1 PC n PS 1 PS m N  M ¿Quién recibe? Indeterminismo Justicia Integridad bPeti PC 1 PC n PS N  1 ¿De quién recibí? PC n enviar (buzon, msj)recibir (buzon, msj) int recibir (buzon, msj) PC n

69 Gestión de Procesos69 Paso de mensajes (Comunicación Indirecta) Los enlaces pueden ser Unidireccionales o Bidireccionales PCPS ¿ Problemas ? PC 1 PS PC 2 ¿ Y aquí ? Lo normal Unidireccionales: bPeti PC PS 1 PS 2 bResp ¿ Código del Cliente y de los Servidores ? Lo más general: B1 P2 P4 P5 B2P3 P1 Varios Procesos Varios Buzones Todo dinámico

70 Gestión de Procesos70 Paso de mensajes (Comunicación Indirecta) type Buzones is private; functionCrear(nombreB: Nombres ) return Buzones; functionConectarse(nombreB: Nombres) return Buzones; procedureEnviar(b: in out Buzones; msj: Mensajes); procedureRecibir(b: in out Buzones; msj: out Mensajes); procedureDestruir(b: in out Buzones); Un modelo: Capacidad * *  Propietario * Excepción  buzonInexistente,... ¡ Problemática Destrucción ! Mensajes en el buzón Procesos bloqueados Referencias a buzones destruidos mqd_t mq_open (const char *name, int oflag, …) int mq_send (mqd_t mqid, const char *msgptr, size_t msgsz, unsigned msgprio) ssize_t mq_receive (mqd_t msid, char *msgp, size_t msgsz, unsigne *msgprio) int mq_close (mqd_t mqid) POSIX

71 Gestión de Procesos71 Planificación de Procesos ( Criterios ) Planificar  Elegir el siguiente Pi a ejecutar JUSTICIA EFICIENCIA RENDIMIENTO MINIMIZAR TIEMPOS Criterios Carga Sin CPU Ejecutándose Pi Tiempo de Retorno CPU Tiempo útil Tiempo inútil Tiempo de Espera ¿Tiempo de Respuesta? Pi Criterios difícilmente alcanzables: Favorecer Pi  Perjudicar Pj

72 Gestión de Procesos72 Planificación de Procesos ( P CPU vs P E/S ) P CPU P E/S Periodos largos de CPU Periodos cortos de CPU ? ¿Cómo reconocerlos? Abandona voluntariamente la UCP

73 Gestión de Procesos73 Sistemas Batch No expulsores o expulsores con un quantum grande Reducen cambios de contexto y mejoran el rendimiento Por niveles, Primero en llegar primero en servir FCFS, Más corto el siguiente SJF, Tiempo restante menor SRTN Sistemas interactivos Expulsores: evita la monopolización de la CPU Round-Robin, prioridades, múltiples colas, Más corto el siguiente SPN (envejecimiento) Sistemas de tiempo real Monotónico en frecuencia Deadline más próximo el siguiente Planificación de Procesos ( Políticas )

74 Gestión de Procesos74 Planificación de Procesos ( Por niveles ) Planificación a medio plazo Memoria Planificación a corto plazo CPU CPU I T2 T2T2 T3T3 T5T5 T 1, T 2, T 3, T 4, T 5, T 6 S.O. Entrada al sistema frecuencia alta frecuencia baja

75 Gestión de Procesos75 Planificación de Procesos ( Primero en llegar FCFS ) Sólo cuando un proceso abandona voluntariamente la CPU, la misma se asigna al proceso que lleva más tiempo preparado (FIFO) DC A B AD B CD B C A E/S Sencillo, pero  Ausencia de política DCBA 4 4 4 8 DCBA 8 4 4 4 Tesp Tret 9 14 Tesp Tret 6 11 “Efecto convoy” {P E/S } n P UCP P E/S {P E/S } n-1 P UCP E/S T >> T <

76 Gestión de Procesos76 Planificación de Procesos ( Efecto convoy ) P UCP = {10UCP + 2E/S}*P E/S = {1UCP + 2 E/S}* P UCP P E/S CPU al 100%, pero tan sólo 30 unidades de tiempo en E/S CPU al 100% y además, 55 unidades de tiempo en E/S P UCP P E/S ??

77 Gestión de Procesos77 Planificación de Procesos ( El más corto primero SJF ) Objetivo: Minimizar Tesp/ret 8 5 4 3 CPU 3458 ¿Óptimo? ¿Dónde esperan los procesos? CPU preparados ¿Aplicable SJF en planificación a largo y a corto plazo? ¿Más corto? Tiempo total de CPU Lo declara el usuario Si engaña  KILL ¿Más corto? Sistemas interactivos Contraejemplo 0123401234 A(2) B(4) C(1) D(1) E(1)

78 Gestión de Procesos78 Variante expulsora del SJF. Cuando llega un trabajo nuevo, comparar su petición de tiempo con el tiempo que le queda al actual. Seleccionar el menor. Favorece a los trabajos nuevos 0123456701234567 A(2) B(4) C(1) D(1) E(1) ¿Tiempo medio de espera? Planificación de Procesos ( Tiempo restante menor SRTN )

79 Gestión de Procesos79 Planificación de Procesos (Round Robin) “Todos iguales”: Turno Rotatorio o Rodajas de Tiempo A cada Pi que pasa a ejecución se le dá una rodaja “cuanto” de tiempo aLa consume totalmente y se le expulsa Pi rodaja bLa usa parcialmente y abandona voluntariamente la UCP Pi sleep, wait, exit Política FIFO de gestión de la cola de preparados Dos cuestiones de diseño: 1¿Cómo elegir el tamaño de la rodaja? 2¿Cómo determinar el fin de rodaja? Ley del 80%

80 Gestión de Procesos80 Planificación de Procesos (Round Robin) 1¿Cómo elegir el tamaño de la rodaja?Sea Tcc = 5 mseg (mucho) aRodaja pequeña 20 mseg => Burocracia del 20% bRodaja grande 500 mseg => Burocracia del 1% UCP útil Respuesta lenta a usuarios interactivos ¿Degenera en FCFS? Mejor interactividad Ejemplo: P1, P2, P3 => 24, 3 y 3. Rodajas 4 vs 12 y Tcc = 0,5 P1P2P3P1 33,5 P1P2P3P1 31,5 Valores comunes: 20..50 mseg

81 Gestión de Procesos81 Planificación de Procesos (Round Robin) 2¿Cómo determinar el fin de rodaja? aUna interrupción periódica P1P2P3P4 sleep ¿Somos justos con P3? ¿viable? F(int) en 68901 [1µseg..20mseg] Dar 2 rodajas Resetear interrupción bSumar ticks de una interrupción más frecuente P1P2 sleep P3P4

82 Gestión de Procesos82 Planificación de Procesos (Prioridades) “Unos más importantes que otros”: Cada Pi prioridad explícita 0 N N 0 mín máx expulsora P3P3 P7P7 P1P1 UCP siempre ejecuta Pi más prioritario UCP libre  ejecutar Pi más prioritario Igualdad de prioridad  FCFS, Round Robin Prioridades estáticas vs dinámicas Sencillo pero inanición P3P3 P7P7 P1P1 P9P9 ¿ tiempo real ? no expulsora P3P3 P7P7 P1P1

83 Gestión de Procesos83 Planificación de Procesos (Prioridades dinámicas) aEvitar la inanición: Disminuir la prioridad a medida que se usa la UCP Aumentar la prioridad si se está tiempo en preparados ¿ Favorece a los trabajos cortos ? bP E/S vs P UCP Favorece a los Pi ligados a E/S ¿Cuáles son P E/S ? ¿Todo el tiempo será P E/S ? P E/S aquellos que usen una parte menor de la rodaja de UCP Ejemplo con rodajas de 100 mseg: P1 usa 2 mseg de UCP  P E/S P2 usa 25 mseg de UCP  P UCP Prio (P1) = 100/2 = 50 Prio (P2) = 100/25 = 4 ¿Rango de prioridades [0..N]? Estáticas muy bajo  16 Dinámicas muy variable

84 Gestión de Procesos84 Planificación de Procesos (Múltiples colas) “Mezcla de políticas”: Cada Pi asociado a una cola de forma estática Prioridad 3 2 1 0 FCFS Round Robin Quantum 4 8 16 Dos elecciones: 1Seleccionar cola 2Seleccionar proceso dentro de la cola ¿Expulsora?

85 Gestión de Procesos85 Planificación de Procesos (Múltiples colas realimentadas) “Mezcla de políticas”: Cada Pi asociado a una cola de forma dinámica aMenos Cambios de Contexto Prioridad 4 3 2 1 0 1 + Rodajas Variables 2 4 8 16 Rodajas para Pi  1, 2, 4, 8, 16 bFavorecer selectivamente P E/S Prioridad 3Terminal 2E/S 1Rodaja corta 0Rodaja larga Consumir rodajas: Bajar de prioridad

86 86 Planificación de Procesos (MINIX 3) /usr/src/kernel/proc.h PiPi SI consumió su rodaja Nueva rodaja Prioridad++ ¡Menor! Encolar_Al_Final SINO Encolar_Al_Principio sched Preparados MaxPrioridad MinPrioridad RoundRobin proc[log].p_nextready

87 Gestión de Procesos87 Planificación de Procesos ( Pi más corto siguiente SPN ) CPU preparados ¿Más corto? SJFSPN Tiempo de próxima posesión de UCP ? ¿Predicción? (  i )   i+1 = F ( t i,  i )  i+1 =  t i + (1-  )  i y  = 1/2 Predicción t i   i  10 6 8 4 6 6 6 4 5 13 9 11 13 12

88 Gestión de Procesos88 Dado m eventos periódicos evento i ocurre en el periodo P i y precisa C i segundos El sistema es planificable si Hard real time vs Soft real time Eventos: periódicos vs aperiódicos (Leer las secciones 7.4.2, 7.4.3 y 7.4.4) Planificación de Procesos ( Sistemas de Tiempo Real )

89 Gestión de Procesos89 Separar qué se puede hacer de cómo hacerlo Un proceso puede saber cuáles de sus threads hijos son los más importantes y asignarles prioridad Algoritmo de planificación parametrizado Mecanismo en el kernel Los procesos de usuario ponen el valor de los parámetros Los procesos de usuario indican la política Planificación de Procesos ( Política vs Mecanismo ) pthread_attr_setschedpolicy(…) => FIFO, RR, OTHERS

90 Gestión de Procesos90 Quantum por proceso de 50 mseg Cada thread ejecuta 5 mseg de ráfaga de CPU Planificación de Threads ( Espacio de usuario )

91 Gestión de Procesos91 Planificación de Threads ( Espacio de kernel ) Quantum por proceso de 50 mseg Cada thread ejecuta 5 mseg de ráfaga de CPU

92 Gestión de Procesos92 Sistemas multiprocesador µP1µP2µP3µP4 Cada µP su cola Peligro de carga desequilibrada µP1µP2µP3µP4 ¡ Ojo !  Spin Lock Planificar  ¿Qué thread? ¿En qué núcleo? 1.Tiempo compartidoThreads independientesCola única No escalable con aumento núcleos Espera activa si FR  Spin Lock ¡Estoy en RC!  Alarga rodaja Problemática caches  Afinidad

93 Gestión de Procesos93 Sistemas multiprocesador Ordenando 128.000 claves “burbuja” en Intel Core 2 Quad Q6600 2,46GHz µP 0 4MB L2 µP 1 µP 2 4MB L2 µP 3 sched_setaffinity

94 Gestión de Procesos94 Sistemas multiprocesador 2.Espacio compartidoThreads cooperantesApropiarse {µP} n Núcleo ocioso cuando Pi.bloqueado Sin multiprogramación  ¡Menos burocracia! Sin “n” núcleos libres no me ejecuto Servidor Web con {threads} variable

95 Gestión de Procesos95 Sistemas multiprocesador 3.Planificar por pandillasThreads cooperantesTiempo/Espacio Espacio compartido Tiempo compartido FIN