Deadlocks
Filósofos comensales
Deadlock Los tenedores son los recursos En una computadora, que recursos tenemos? CPU, memoria, placa gráfica, teclado, HD, impresora, CD writer Cuales recursos pueden generar deadlocks? Todos?
Deadlock Los recursos que no son fácilmente expropiables Típicamente recursos que se pueden usar exclusivamente, por ej. grabadora de CD, impresora, placa de sonido CPU, memoria: no problem
Definición de deadlock Un conjunto de procesos está en deadlock si todos los procesos del conjunto esperan un evento que sólo puede producir un proceso de ese mismo conjunto Instancia: Un conjunto de procesos está en deadlock si todos los procesos del conjunto esperan algún recurso ocupado por otro proceso del mismo conjunto.
Otros Deadlocks el típico: esperando recursos otros: esperando eventos como ser un mensaje de la red, o que ocurra algo particular en el sistema ej. que se cree cierto archivo, o que otro proceso deje de ejecutarse,...
Condiciones necesarias Para que se produzca un deadlock, tiene que pasar: 1. Exclusión mutua: cada recurso está siendo ocupado por a lo sumo un proceso 2. Retención y espera: Los procesos que tienen recursos previamente otorgados pueden solicitar otros recursos. 3. No expropiación: Los recursos asignados no pueden quitarse (expropiarse) a la fuerza. Todo proceso debe liberar los recursos voluntariamente.
Condiciones necesarias 4. Espera circular: Existe una cadena circular de espera entre 2 o más procesos. Q: donde están las 4 condiciones acá?
Modelado de deadlocks A través de grafos bipartitos dirigidos llamados grafos de asignación de recursos (a): A usa R (b) B espera S Ciclo en grafo ==> deadlock!
Estrategias para lidiar con deadlocks 1. Ignorar compromiso entre corrección y diseño 2. Detección y recuperación 3. Evitar dinámicamente mediante la asignación cuidadosa de recursos 4. Prevenirlo por diseño (prohibiendo alguna de las 4 condiciones necesarias)
Tipos de recursos Hasta ahora hemos asumido que cada recurso tiene un tipo único ej. un sistema con un sólo CD y una sola impresora En la práctica conviene asumir varios recursos de cada tipo Por ejemplo, las impresoras, los CD, Un proceso pide algún recurso de un tipo dado (sin importar cuál recurso en particular se le asigna)
Detección y recuperación Detección con un recurso de cada tipo Nos basta con detectar ciclos en el grafo de asignación de recursos El SO lleva una representación del grafo que actualiza en cada pedido/liberación de recurso, y que chequea por ciclos Esto puede ser muy costoso! Alternativamente el SO chequea cada k minutos/segundos
Ejemplo A pide R, S y luego libera R, S B pide S, T y luego libera S, T C pide T, R, y luego libera T, R Puede llegar a deadlock? depende de como son planificados!
Ejemplo
Ejemplo Una ejecución que lo evita
Cómo encontrar ciclos en un grafo Caso general ineficiente: hacer una búsqueda DFS desde cada nodo, buscando caminos con nodos repetidos Caso particular eficiente (para ciclos de long. <= 4) Tenemos n nodos. Inicializar una matriz A nxn con ceros Idea: para cada par de nodos j,k vecinos de un nodo i, ver si ellos están conectados entre sí (directa o indirectamente)
Cómo encontrar ciclos en un grafo Para cada nodo i: Si A[j,k] == 0 Set A[j,k] = 1 y continuar Si A[j,k]==1 Ciclo! Complejidad O(n^2): necesitamos recorrer la matriz nxn
Detección con varios recursos de cada tipo Buscar ciclos ya no funciona Cada nodo es ahora como una caja que contiene recursos Vamos a ver un algoritmo basado en matrices
Detección con varios recursos de cada tipo Tenemos n procesos y m clases de recursos E=(E1,...,Em) Ej: cantidad de recursos tipo j en existencia A=(A1,...,Am) Aj: cantidad de recursos tipo j disponibles (Availables) C = [Cij] 1<=j<=m, 1<=i<=n Cij: cantidad de recursos de tipo j ocupados por el proceso i al momento (Current)
Detección con varios recursos de cada tipo R = [Rij] 1<=j<=m, 1<=i<=n Rij: cantidad de recursos tipo j solicitados por el proceso i (Request) Ri son todos los recursos que va a pedir el proceso i durante su ejecución
Detección con varios recursos de cada tipo Def. Sean A=(A1,...,An) y B=(B1,...,Bn). Entonces A<=B sii Aj<=Bj para todo 1<=j<=n La suma tambien se define punto a punto
Formalizando Deadlocks Un deadlock es una propiedad sobre ejecuciones. Definimos un estado de un proceso como s = <A,C,R> Definimos un paso de ejecución como una relación entre estados s->s : <A,C,R> <A,C,R > donde se asignan o liberan recursos Estado inicial: s0 = <E, <0,...,0>, R0> Ejecucion: s0 sj
Formalizando Deadlocks recordar: <A,C,R> ejemplo: E=<10,5>, R1=<2,3>, R2=<1,2> <E, <0,...,0>, <R1,R2> > --> { se otorga R1 } <E-R1, <R1,0>, <0,R2> > --> { se otorga R2 } <E-R1-R2, <R1,R2>, <0,0> > --> { se libera R1 } <E-R2, <0,R2>, <0,0> > --> { se libera R2 } <E, <0,0>, <0,0> >
Invariante Para todo j, 1<=j<=m: Aj + Sum_1<=i<=n Cij = Ej Qué quiere decir? Todo recurso está libre o asignado
Formalizando Deadlocks No hay deadlock: Para toda ejecución s0->...-> sn=<a,c,r>, existe i tq. Ri <= A Hay deadlock: Existe una ejecución s0->...-> sn=<a,c,r> tq. para todo i, Ri>A Queremos hacer un algoritmo para detectar estos deadlocks! idea: simular que los procesos piden todos los recursos que necesitan hasta el final cdo. terminan
od Algoritmo detección Do safe(r,a) Pueden_ejecutar := empty while (existe i: 1<=i<=n : i no pert. pueden_ejecutar y Ri<=A) do od elegir i tq i no pertenece a Pueden_ejecutar y Ri<=A Pueden_ejecutar:=Pueden_ejecutar U {i} A:=A + Ci; Ci:=0; Procesos_en_deadlock:={1,...,n} Pueden_ejecutar Return (procesos_en_deadlock == empty)
Algoritmo detección Invariante: Para todo j, 1<=j<=m: Aj + Sum_1<=i<=n Cij = Ej Qué quiere decir? Todo recurso está libre o asignado Cómo se prueba en el algoritmo?
Algoritmo detección Idea: se van eligiendo procesos y comparando si se pueden ejecutar o no Ejemplo: 2 procesos 1,2; 3 tipos de recursos A=<4,6,1>, C1 =<1,0,1>, C2=<0,1,0> R1 = <1,2,1>, R2 = <0,3,1> Elijo i=1, pueden_ejecutar={1}, A=<5,6,2> Elijo i=2, pueden_ejecutar={1,2}, A=<5,7,2> Pude haber elegido al reves!
Algoritmo detección El algoritmo es nodeterministico! (se puede ejecutar de diferentes maneras) Como se que siempre da lo mismo? No seria bueno que a veces diga que hay deadlock y a veces no!
Algoritmo detección Prueba (informal): si elijo i0, i1 en el loop, el resultado es el mismo que si hubiera elegido i1,i0 A:=A + Ci0 + Ci1 ; Ci0:=0; Ci1:=0; Pueden_ejecutar U {i0} U {i1} es igual que A:=A + Ci1 + Ci0 ; Ci1:=0; Ci0:=0; Pueden_ejecutar U {i1} U {i0} Propiedades necesarias: conmutatividad y asociatividad de + y U
Otro ejemplo
Recuperación de deadlock Una vez que detectamos el deadlock, qué hacemos? Estrategias de recuperación: expropiación: sacarle un recurso a un proceso a la fuerza como todo recurso no es expropiable, la recuperación del proceso que sufrió la expropiación es difícil o imposible usualmente requiere intervención manual
Recuperación de deadlock Recuperación por rollback (vuelta atrás) Requiere haber hecho checkpoints de los procesos (guardar el estado=memoria/estado recursos/pcb... en momentos adecuados) en caso de deadlock hacemos un rollback a un punto anterior de algún proceso que esta bloqueado Técnica estándar en base de datos llamada transacción
Recuperación de deadlock Killing de procesos elegir una víctima según costos cantidad de recursos asignados, cantidad de trabajo completado facilidad de reiniciar sin efectos dañinos (por ej. una compilación es más fácil de reiniciar que B. de Datos)
Evitar deadlocks Queremos utilizar el grafo o matriz de asignación de recursos para construir una estrategia (planificación/scheduling) que evite el deadlock (no sólo detectarlo) Antes el R era lo que pedía un proceso en ese momento. Ahora tenemos un R máximo, y en cada momento un proceso pide R' <= R ejemplo: E=<10,5>, R =<2,3>, R =<11,6> <E, <0>, <R'> > --> <E-R', <R >, <R''> >
Trayectorias de recursos dos procesos A y B, dos recursos Printer y Plotter. I1: A pide printer. I2: A pide plotter. I3-I4: A deja printer y plotter. I5: B pide plotter. I6: B pide printer. I7-I8: B deja.
Trayectorias de recursos las áreas interlineadas son imposibles! el cuadrado I1-I2-I5-I6 es inseguro donde está el deadlock? en el punto t, B pide el plotter, que debe hacer el planificador? lo debe ignorar para esquivar las áreas peligrosas
Estado seguro Un estado es seguro si 1. no está en deadlock y 2. existe una planificación que permite la ejecución satisfactoria de todos los procesos aún si todos repentinamente solicitan el máximo número de recursos posibles para cada uno Un estado es inseguro si no es seguro está en deadlock, o bien no hay una planificación cuando todos piden el máximo de recursos
Ejemplo (1 recurso de c/tipo)
Ejemplo (varios recursos de c/tipo) es seguro?
Estado seguros un estado seguro nos asegura que no vamos a entrar en deadlock un estado inseguro no dice nada: podemos caer en deadlock o no: por ej. si los procesos nunca piden su máximo, o devuelven los asignados durante su ejecución El método para saber si un estado es seguro es el mismo que para detectar un deadlock!
Algoritmo del banquero Dijkstra 65: una cartera de clientes con una línea de créditos máxima por cliente. A cada pedido de dinero el banquero tiene que decidir si le otorga o no teniendo en cuenta que si de golpe todos piden el máximo, existe algún orden en el cual puede satisfacerse (teniendo en cuenta las reservas del banco) dinero->?, clientes->?, máximo crédito->?, reservas->?
Algoritmo del banquero (múltiples recursos) proc request(i:pid, rq: array [1..n] of Nat) if not(rq<= Ri) -> error( pide mas de lo declarado ) elsif not(eq<=a) -> error( pide mas de lo disponible ) elsif rq<=ri and rq<=a --> A,C,R := A,C,R; A:=A-rq; Ri:=Ri - rq; Ci:=Ci+rq; if safe(r,a) --> otorgar recursos.. elsif not(safe(r,a)) --> A,C,R:=A,C,R ; sleep(proc[i]); endif endif end
Ejemplo (varios recursos de c/tipo) Sup. que B pide un scanner. Se otorga? Y si luego E pide otro scanner mas? (el último)
Algoritmo del banquero no se usa en la práctica difícil de establecer R a priori los procesos varían dinámicamente (se crean y se terminan) lo que complica el cálculo de estado seguro prevenir dinámicamente no sirve, qué hacemos? prevenir estáticamente
Prevención estática Evitar exclusión mutua muy difícil porque en general los recursos se usan en modo exclusivo en algunos casos podemos hacer spooling como en la impresora el único que accede a la impresora es el daemon, los demás a través de un buffer ahora hay MUTEX en el buffer del HD! la idea entonces es minimizar el tiempo de retención de los recursos
Prevención estática Evitar retención y espera Por ej., pedir todos los recursos juntos: todo o nada hacerlo en orden, o atómicamente tiene el mismo problema que el banquero: asume a priori saber todos los recursos que se necesitan Alternativa: primero pedir un recurso, y luego cuando se necesita otro recurso, soltar y pedir los 2 sirve pero es ineficiente!
Prevención estática generalización: 2 phase commit: fase 1 : pedir todos los recursos si no se puede soltar todos fase 2: trabajar y al final liberar todos
Prevención estática Expropiación ya hablado! prácticamente imposible Evitar espera circular ordenar los recursos y sólo pedir si ese orden se respeta Por ejemplo, los recursos siempre se piden: 1. scanner, 2. cd-rom, 3. impr. podemos empezar en cualq. lugar! muy difícil de satisfacer en general
Communication deadlocks A le manda a B un mensaje y espera respuesta. B espera el mensaje, pero se pierde en el camino. A y B están en deadlock! como están en red, es más dificil de prevenir/recuperarse no se puede expropiar (no hay recurso!) ni prevenir por planificación (los procesos están en diferentes máquinas!) se usan temporizadores (timeouts)
Deadlocks distribuídos Los recursos no necesariamente están en la misma máquina por ejemplo, un buffer en un router es un recurso compartido que almacena paquetes en tránsito pueden haber deadlocks distribuídos!
Centralized deadlock prevention se arma el grafo de asignación distribuido cada nodo manda sus aristas a un lugar central problemas cuando se pierden mensajes o llegan en orden diferente! http://www.cs.rutgers.edu/~pxk/rutgers/notes/content/deadlocks.pdf