El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Administración de procesos: Bloqueosmutuos y políticas
Gunnar Wolf
Facultad de Ingeniería, UNAM
2013-02-20 — 2013-02-25
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Índice
1 El SO y los Bloqueos mutuos
2 Prevención
3 Evasión
4 Detección y recuperación
5 La triste realidad. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Generalizando bloqueos mutuos
Estudiamos ya varios casos de bloqueos mutuos al hablarde sincronizaciónPueden presentarse en varios otros entornos
De cómputo o de la vida real
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El encuentro de dos trenes
Cuando dos trenes lleguen a un crucero, ambosdeben detenerse por completo y no avanzar hastaque el otro se haya ido
Ley aprobada por el Estado de Kansas, principios del siglo XX
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El cruce de un semáforo
Cuando dos personas llegan a un crucero sin semáforo,¿quién tiene el paso?
Reglamento de tránsito: El conductor que viene más porla derecha¿Y qué procede cuando cuatro conductores llegan a lavez?
Legalmente, los cuatro deben detenerse y nunca másavanzarUno podría echarse en reversa, otro podría ignorar la ley ypasar de todos modos, ¡pero es porque los conductoreshumanos tienen iniciativa!
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El cruce de un semáforo
Cuando dos personas llegan a un crucero sin semáforo,¿quién tiene el paso?
Reglamento de tránsito: El conductor que viene más porla derecha¿Y qué procede cuando cuatro conductores llegan a lavez?
Legalmente, los cuatro deben detenerse y nunca másavanzarUno podría echarse en reversa, otro podría ignorar la ley ypasar de todos modos, ¡pero es porque los conductoreshumanos tienen iniciativa!
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El cruce de un semáforo
Cuando dos personas llegan a un crucero sin semáforo,¿quién tiene el paso?
Reglamento de tránsito: El conductor que viene más porla derecha¿Y qué procede cuando cuatro conductores llegan a lavez?
Legalmente, los cuatro deben detenerse y nunca másavanzarUno podría echarse en reversa, otro podría ignorar la ley ypasar de todos modos, ¡pero es porque los conductoreshumanos tienen iniciativa!
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
¿Cuándo se presenta un bloqueo mutuo?
Condiciones de Coffman
Exclusión mutua Los procesos reclaman acceso exclusivo delos recursos
Espera por Los procesos mantienen los recursos que ya leshabían sido asignados mientras esperan recursosadicionales
No apropiatividad Los recursos no pueden ser extraídos de losprocesos que los tienen hasta su completautilización
Espera circular Existe una cadena circular de procesos en quecada uno mantiene a uno o más recursos que sonrequeridos por el siguiente en la cadena
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Evaluando en base a las conidiciones de Coffman
Cada una de las condiciones presentadas son necesarias,pero no suficientes para que haya un bloqueoPero pueden alertarnos hacia una situación de riesgoCuando se presentan las cuatro, tenemos un bloqueomutuo que sólo puede resolverse terminando a uno de losprocesos involucrados
Pérdida de datos / estado
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo clásico de bloqueo mutuo (1)
Asumimos: Un sistema con dos unidades de cinta (accesosecuencial, no-compartible)
Dos procesos, A y B, requieren de ambas unidades.
1 A solicita una unidad de cinta y se bloquea2 B solicita una unidad de cinta y se bloquea3 El sistema operativo otorga la unidad 1 a A y lo vuelve a
poner en ejecución4 A continúa procesando; termina su periodo de ejecución5 El sistema operativo otorga la unidad 2 a B y lo vuelve a
poner en ejecución
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo clásico de bloqueo mutuo (2)
6 B solicita otra unidad de cinta y se bloquea7 El sistema operativo no tiene otra unidad de cinta por
asignar. Mantiene a B bloqueado; otorga el control devuelta a A
8 A solicita otra unidad de cinta y se bloquea9 El sistema operativo no tiene otra unidad de cinta por
asignar. Mantiene a B bloqueado; otorga el control devuelta a otro proceso (o queda en espera)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Esquematizando el ejemplo clásico
Figura: Esquema clásico de un bloqueo mutuo simple: Los procesosA y B esperan mutuamente para el acceso a las unidades de cinta 1y 2.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El punto de vista del sistema operativo
El rol del sistema operativo va más allá de lo presentadoen las láminas anteriores (Exclusión mutua)No podemos asumir que los procesos cooperarán entre sí
Ni siquiera que sabrán por anticipado de la existenciamutua
Un rol primario del sistema operativo es gestionar losrecursos del equipo
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Políticas de prevención o resolución de bloqueosmutuos
Si el sistema establece políticas respecto a la asignación derecursos, puede evitar casos como el presentado.Las políticas pueden verse en un contínuo entre:
Liberales Buscan a otorgar los recursos lo antes posiblecuando son solicitados
Conservadoras Controlan más el proceso de asignación derecursos
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Espectro liberal-conservador de políticas
Figura: Espectro liberal—conservador de esquemas para evitarbloqueos
Volveremos a este diagrama hacia el final del tema
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Categorías de estrategias ante bloqueos mutuos
Prevención Modela el comportamiento del sistema paraeliminar toda posibilidad de un bloqueo.Resulta en una utilización subóptima de recursos.
Evasión Impone condiciones menos estrictas. No puedeevitar todas las posibilidades de un bloqueo;cuando éste se produce busca evitar susconsecuencias.
Detección y recuperación Permite que ocurran los bloqueos,pero busca determinar si ha ocurrido y actuarpara eliminarlos.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Índice
1 El SO y los Bloqueos mutuos
2 Prevención
3 Evasión
4 Detección y recuperación
5 La triste realidad. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Característica básica
Modela el comportamiento del sistema para eliminar todaposibilidad de un bloqueo.
Resulta en una utilización subóptima de recursos.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Serialización
Previene caer en bloqueos negando que el sistema otorguerecursos a más de un proceso a la vezLos diferentes procesos pueden seguir ejecutando
Realizando cálculosEmpleando recursos no rivales
Podría emplearse en un esquema tipo multiprogramacióntemprana (no interactiva)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Serializando el ejemplo clásico de bloqueo mutuo(1)
1 A solicita una unidad de cinta y se bloquea2 B solicita una unidad de cinta y se bloquea3 El sistema operativo otorga la unidad 1 a A y lo vuelve a
poner en ejecución4 A continúa procesando; termina su periodo de ejecución5 El sistema operativo mantiene bloqueado a B, dado que
A tiene un recurso6 A solicita otra unidad de cinta y se bloquea
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Serializando el ejemplo clásico de bloqueo mutuo(2)
7 El sistema operativo otorga la unidad 2 a A y lo vuelve aponer en ejecución
8 A libera la unidad de cinta 19 A libera la unidad de cinta 2 (y con ello, el bloqueo de
uso de recursos)10 El sistema operativo otorga la unidad 1 a B y lo vuelve a
poner en ejecución11 B solicita otra unidad de cinta y se bloquea12 El sistema operativo otorga la unidad 2 a B y lo vuelve a
poner en ejecución13 B libera la unidad de cinta 114 B libera la unidad de cinta 2
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Analizando a la serialización
Previene toda posibilidad de bloqueo ante solicitud derecursosPero se vuelve muy susceptible a la inaniciónLleva a subutilización de los recursos
Con n procesos, puede haber n-1 esperando a que unolibere los recursos.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Retención y espera o Reserva (advance claim)
Política de prevención menos conservadoraTodos los programas al iniciar su ejecución declaran quérecursos requeriránApartados para uso exclusivo hasta que el proceso terminaEl sistema puede seguir concediendo solicitudes que norivalicen
Si C y D requieren recursos diferentes de A y B, puedenejecutarse en paralelo A, C y DPosteriormente, B, C, D
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Desventajas de la retención y espera
Recursos reservados por toda la ejecución del procesoIncluso si la requieren por un tiempo muy limitado
Percepción de injusticia por inaniciónTiempo de espera para el usuario que lanzó B
Requiere que el programador sepa por anticipado losrecursos que requerirá
Muchas veces es imposible
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Solicitud de una vez (one-shot)
Otro mecanismo de prevención de bloqueosUn proceso sólo puede solicitar recursos cuando no tieneninguno
Dos variantes: Todos de inicio, o soltar y readquirir
Rompe la condición de espera por. . . ¡Pero hay muchos recursos que deben mantenersebloqueados por largo plazo!Cambia la lógica de programación al tener puntosdefinidos de adquisición y liberación
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Asignación de recursos jerárquica
A cada categoría de recursos se le asigna una prioridad onivel jerárquicoUn proceso dado sólo puede solicitar recursos de un nivelsuperior a los que ya tiene asignados.
Para pedir dos dispositivos del mismo nivel, debe hacersede forma atómicaSi tanto P1 como P2 requieren dos unidades de cinta,ambos deben pedirlas a ambas de una sola vezEl planificador elegirá cuál gana; ese tendrá ambosrecursosEl otro esperará hasta que éste termineNo hay bloqueo
Podríamos presentar a la solicitud de una vez como uncaso degenerado de asignación jerárquica.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Asignación de recursos jerárquica
Si P1 y P2 requieren una impresora y una unidad de cinta,hay un órden claro en que tienen que pedirse
No hay bloqueoLos recursos más escasos están más arriba en la jerarquía
Esto hace que lleguen menos solicitudes por ellos
. . . ¿Pero?
Es un ordenamiento demasiado estricto para muchassituaciones del mundo realLleva a los procesos a acaparar recursos de baja prioridadConduce a inanición
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Sorteando los mecanismos de prevención
¿Podemos burlar estos mecanismos?P.ej. empleando procesos representantes (proxy)
Un programador poco cuidadoso puede, sin llegar abloqueo por recursos, llegar a un bloqueo por procesos
Pero una buena práctica sería descargar el uso derecursos rivales en un proceso que sepa cómocompartirlos inteligentemente
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Prevención de bloqueos: Resumiendo
Mecanismos muy conservadores pero 100% efectivos (sinos limitamos a lo declarado...)Parecerían poco acordes a un entornomultiusuario/multitarea como la mayoría de los actualesSin embargo, empleados para ciertos subsistemas, conesquemas de mediación
ImpresiónAudio
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Índice
1 El SO y los Bloqueos mutuos
2 Prevención
3 Evasión
4 Detección y recuperación
5 La triste realidad. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Característica básica
Impone condiciones menos estrictas. No puede evitar todas lasposibilidades de un bloqueo; cuando éste se produce busca
evitar sus consecuencias.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Enfoque 1: Flujos seguros e inseguros
Realizado por el planificadorRequiere saber por anticipado qué procesos utilizarán quérecursos
Un poco menos detallado que la prevención (número derecursos por categoría)
Saber cuándo se va a usar cada recursoAnálisis de la interacción, marcando áreas de riesgo
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Flujos seguros e inseguros
Figura: Evasión de bloqueos: Los procesos A (horizontal) y B(vertical) requieren del acceso exclusivo a un scanner y unaimpresora. Nota: El diagrama debe leerse como estados nodiscretos. (La Red, p. 200)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Áreas de riesgo
Mientras avancemos por el área segura no hay riesgo debloqueosSistemas uniprocesador, sólo avance vertical/horizontal
Sistemas multiprocesador, avance diagonal
Áreas de riesgo: Cuando alguno de los recursos rivales esotorgadoEl bloqueo mutuo se produce en la intersección de I2—I3e I6—I7En la situación descrita, el sistema debe mantener a Bcongelado por lo menos asta que A llegue a I3
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Analizando esta estrategia
Muy dificil de implementar en un sistema de propósitogeneral
Requiere análisis estático previo del códigoO requisitos de programación diferentes a los expuestospor los sistemas en uso generalizado
Puede especificarse dentro de un marco de desarrollo:Asignación de recursos por subrutina
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Enfoque 2: Algoritmo del banquero
Edsger Djikstra, para el sistema operativo THE,1965-1968El sistema procede cuidando de la liquidez para siemprepoder satisfacer los préstamos (recursos) de sus clientesPermite que el conjunto de recursos solicitados por losprocesos sean mayores a los disponibles
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Requisitos para el Algoritmo del banquero
Debe ejecutarse cada vez que un proceso solicita recursosTodo proceso debe declarar su reclamo máximo (claim)de recursos al iniciar su ejecución
Si el reclamo en cualquier categoría es superior almáximo existente, el sistema niega la ejecución
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estructuras a emplear: Relativas a procesos
Matrices (llaves por categoría y por proceso)
Reclamado Número de instancias de este recurso que hansido reclamadas
Asignado Número de instancias de este recurso actualmenteasignadas a procesos en ejecución
Solicitado Número de instancias de este recurso actualmentependientes de asignar (solicitudes hechas y nocumplidas)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estructuras a emplear: Categorías de recursos
Listas (llave por categoría)
Disponibles Número total de instancias de este recursodisponibles al sistema
Libres Número de instancias de este recurso que noestán actualmente asignadas a ningún proceso
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estados
Estado Matrices de recursos disponibles, reclamosmáximos y asignación de recursos a los procesosen un momento dado
Estado seguro Un estado en el cual todos los procesos puedenejecutar hasta el final sin encontrar un bloqueomutuo.
Estado inseguro Todo estado que no garantice que todos losprocesos puedan ejecutar hasta el final sinencontrar un bloqueo mutuo.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Lógica del algoritmo del banquero
Cada vez que un proceso solicita recursos, se calcula cuál seríael estado resultante de otorgar dicha solicitud, y se otorga
siempre que:
No haya reclamo por más discursos que los disponiblesNingún proceso solicite (o tenga asignados) recursos porencima de su reclamoLa suma de los recursos asignados por cada categoría nosea mayor a la cantidad de recursos disponibles en elsistema para dicha categoría
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Definiendo estados seguros
Un estado es seguro cuando hay una secuencia de procesos(denominada secuencia segura) tal que:
1 Un proceso j puede necesariamente terminar su ejecuciónIncluso si solicitara todos los recursos que reservó en sureclamoSiempre debe haber suficientes recursos libres parasatisfacerlo
2 Un segundo proceso k de la secuencia puede terminar:Si j termina y libera todos los recursos que tieneSiempre que sumado a los recursos disponibles ahora,con aquellos que liberaría j, hay suficientes recursos libres
3 El i-ésimo proceso puede terminar si todos los procesosanteriores terminan y liberan sus recursos.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Peor caso con el algoritmo del banquero
En el peor de los casos, esta secuencia segura nos llevaría abloquear todas las solicitudes excepto las del proceso único en
el órden presentado.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo
Asumiendo que tenemos sólo una clase de recursos y nosquedan dos instancias libres:
Proceso Asignado ReclamandoA 4 6B 4 11C 2 7
1 A puede terminar porque sólo requiere dos instanciasadicionales
2 Terminado A, C puede recibir las 5 restantes que requiere3 Terminados A y C, B puede satisfacer las 74 La secuencia A-C-B es segura.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 2
Sólo una clase de recursos, 2 instancias libres
Proceso Asignado ReclamadoA 4 6B 4 11C 2 9
1 A puede satisfacer su demanda2 Pero una vez terminado A, no podemos asegurar las
necesidades ni de B ni de C3 Este es un estado inseguro, por lo cual el algoritmo del
banquero no debe permitir llegar a él.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 3: Paso por paso
¿Hasta dónde nos dejaría avanzar el algoritmo del banquero?
Estado inicial:8 recursos disponiblesReclamos: P1: 5, P2: 5, P3: 4
t1: P1 con 2, P2 con 1, P3 con 1t2: P2 solicita 1t3: P3 solicita 1t4: P1 solicita 1
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 3: Paso por paso
Imagen: Samuel Oporto Díaz
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 3: Paso por paso
Imagen: Samuel Oporto Díaz
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 3: Paso por paso
El algoritmo nos permite avanzar por t1, t2, t3Uso efectivo de recursos del sistema: 14Sobrecompromiso (overcommitment) ante los 8 recursosreales
Al llegar a t4, otorgar un recurso a P1 nos ubica en unestado inseguro
Es imposible satisfacer el reclamo completo de P1, P2 oP3Desde t3, sólo podemos otorgar recursos a P3P1 y P2 pueden seguir ejecutando si no solicitan recursos
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Implementación ejemplo (para una sóla categoría)
1 l = [1, 2, 3, 4, 5]; # Todos los procesos del sistema2 s = []; # Secuencia segura3 while ! l.empty? do4 p = l.select {|id| asignado[id] - reclamado[id] >
libres}.first5 raise Exception, ’Estado inseguro’ if p.nil?6 libres += asignado[p]7 l.delete(p)8 s.push(p)9 end10 puts "La secuencia segura encontrada es: %s" % s
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Precisiones
En el ejemplo 2, es posible que ni B ni C requirieran yatodos sus recursos reclamadosPero el estado es inseguro.El algoritmo del banquero, en el peor caso, puede tomarO(n!)
Típicamente toma O(n2)Hay refinamientos a este algoritmo que reducen su costode ejecución
Puede ser llamado con muy alta frecuencia
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Precisiones
Es un algoritmo conservador: Evita entrar en estadosinseguros a pesar de que no lleve con certeza a unbloqueo mutuo
Pero es la política más liberal que evita los bloqueos sinconocer órden y tiempo de necesidad de recursos.
Desventaja de todos los algoritmos basados en la evasión:Requieren saber por anticipado los reclamos máximos
No siempre es posible con el modelo actual decomputación
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Índice
1 El SO y los Bloqueos mutuos
2 Prevención
3 Evasión
4 Detección y recuperación
5 La triste realidad. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Característica básica
Permite que ocurran los bloqueos, pero busca determinar si haocurrido y actuar para eliminarlos.
A diferencia de la prevención y la evasión, las cuatrocondiciones de Coffman pueden presentarse.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Funcionamiento básico
Se ejecuta como una tarea periódicaBusca limitar el impacto de los bloqueos existentes en elsistema(Discutiremos al respecto más adelante. . . )
Mantenemos una lista de recursos existentes, asignados ysolicitadosEliminando lo obviamente resuelto, nos quedamos con loobviamente bloqueado
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Representación con grafos dirigidos
Procesos con cuadradosRecursos con círculos
Puede representarse una clase de recursos como uncírculo grande, conteniendo círculos pequeños indicandorecursos idénticosSi un proceso puede solicitar un recurso específico (y nocualquiera de una categoría), no son idénticos
Flecha de un recurso a un proceso: El recurso estáasignado al proceso.Flecha de un proceso a un recurso: El proceso estásolicitando al recurso.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estrategia general
Tenemos la representación completa de los recursos yprocesos en el sistemaBuscamos reducir la gráfica, retirando los elementos queno aportan información relevante:
1 Los procesos que no estén solicitando ni tienen asignadoun recurso
2 Para los procesos restantes: Si todos los recursos quesolicitan pueden ser concedidos (no están concedidos aotro), eliminamos al proceso y a todas sus flechas.
Repetimos cuantas veces sea posible3 Si no quedan procesos en el grafo, no hay interbloqueos y
podemos continuar4 Los procesos “irreductibles” están en bloqueo mutuo.
Proceder según la política del sistema
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 1
Figura: Detección de ciclos denotando bloqueos: Grafo de procesosy recursos en un momento dado
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Resolviendo el ejemplo 1
1 Reducimos por B, dado que actualmente no estáesperando a ningún recurso
2 Reducimos por A y F, dado que los recursos por los cualesestán esperando quedarían libres en ausencia de B
3 Quedamos con un interbloqueo entre C, D y E, en torno alos recursos 4, 5 y 7.
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 2
Figura: Ejemplo con categorías de recursos (Imágenes: SamuelOporto Díaz)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 2
Figura: Resultado de reducir por P9
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 2
Figura: Resultado de reducir por P7
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Ejemplo 2
Figura: Resultado de reducir por P8
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
¡No todo ciclo es un bloqueo!
Figura: Al manejar categorías de recursos, no siempre un cicloimplicará un bloqueo
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Bloqueado vs. bloqueando
Reducir un proceso no implica que este haya entregadosus recursos
Sólo que está en posibilidad de hacerloPuede haber inanición por parte de cualquier proceso queespera
Podría agregarse a este algoritmo una ponderación portiempo excesivo de retención
Pero causaría muchos falsos positivos → ¡Muchos casosde procesos finalizados sin necesidad!
Ahora. . . Una vez detectado el bloqueo, ¿qué procede?
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Mátelos, luego ‘virigüa
Terminar a todos los procesos bloqueadosTécnica más sencilla y más justa. . .
Para cierta definición de justicia
Maximiza la pérdida de información
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Retroceder al último punto de control (checkpoint)
Sólo cuando el sistema implementa esta funcionalidadSólo cuando ninguno de los procesos depende de factoresexternosRetroceder en el tiempo, ¿no llevaría a un nuevo bloqueo?Los bloqueos están ligados al órden específico de ejecuciónProbablemente otro orden específico se salve del bloqueo
Y si no. . . Se vuelve una vez más.Tal vez, agregar un contador de intentos que cambie elplanificador
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Retroceder al último punto de control (checkpoint)
Sólo cuando el sistema implementa esta funcionalidadSólo cuando ninguno de los procesos depende de factoresexternosRetroceder en el tiempo, ¿no llevaría a un nuevo bloqueo?Los bloqueos están ligados al órden específico de ejecuciónProbablemente otro orden específico se salve del bloqueo
Y si no. . . Se vuelve una vez más.Tal vez, agregar un contador de intentos que cambie elplanificador
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Terminación selectiva / limitada
Terminar forzosamente, uno a uno (y no en bloque), a losprocesos bloqueados
Terminar a uno y re-evaluar el estadoLos restantes pueden continuar operando
¿Cómo elijo al desafortunado? Varias estrategias. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estrategias para elegir el proceso a terminar (1)
Los procesos más sensibles para detener/relanzar: Los quedemandan garantías de tiempo real. Evitar penalizarlos.Causar una menor pérdida de trabajo. El que hayaconsumido menor cantidad de procesador hasta elmomento.Mayor tiempo restante estimado (si puedo estimar cuántoprocesamiento queda pendiente)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Estrategias para elegir el proceso a terminar (2)
Menor número de recursos asignados hasta ahora (comocriterio de justicia: ¿qué proceso está haciendo un usomás juicioso del sistema?)Prioridad más baja (cuando la hay)Procesos con naturaleza repetible sin pérdida deinformación (aunque sí de tiempo)
p.ej. es mejor interrupmir una compilación que laactualización de una BD
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Periodicidad del chequeo
Si buscamos bloqueos cada vez que se solicita un recurso,es una sobrecarga administrativa demasiado grandeCon una periodicidad fija: Arriesga a que los procesospasen más tiempo bloqueados (≈ 0,5t)Cuando el nivel de uso del CPU baje de cierto porcentaje
Indica que hay un nivel elevado de procesos en espera. . . Pero un sistema demasiado ocupado puede nuncadisparar esta condición
Una estrategia combinada
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Índice
1 El SO y los Bloqueos mutuos
2 Prevención
3 Evasión
4 Detección y recuperación
5 La triste realidad. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Frustraciones. . .
Les advertí que este tema me resultaba frustranteHemos visto varios enfoques a cómo lidiar con lapresencia de bloqueosEs un área viva y activa de investigación, y vieneavanzando desde los primeros días del multiprocesamientoSin embargo. . .
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Recapitulando: Conservadores y liberales
./ltxpng/deadlocks_conserv_lib.png
Figura: Espectro liberal—conservador de esquemas para evitarbloqueos
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El Algoritmo del avestruz
Mecanismo más frecuente utilizado por los sistemasoperativos de propósito generalIgnorar las situaciones de bloqueoEsconder la cabeza bajo tierra y esperar a que pasenEsperar que su ocurrencia suficientemente poco frecuenteEsperar que el usuario detecte y resuelva el problema porsí sólo
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
El por qué del avestruz
Las condiciones impeustas por las diversas estrategias soncasi imposibles de alcanzarConocimiento previo de requisitos insuficienteBloqueos originados fuera de nuestra esfera de acción
Recursos externosProcesos representanteEstructuras a niveles superiores
Modelo de computación tendiente al interactivoEn servidores: Programas (¡y personas!) dedicados almonitoreo
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Cuestión de compromisos
Un sistema operativo de propósito general tiene quefuncionar para muy distintas situaciones
Es muy difícil plantear esquemas aptos para todanecesidad
Debe tomarse una decisión entre lo correcto y loconveniente
Un SO no debería permitir que hubiera bloqueosPero la inconveniencia a usuarios y programadores seríademasiada
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Cuestión de programar defensivamente
El programador puede tomar ciertas medidas para evitar quesu programa caiga en situaciones de bloqueo
Solicitar recursos con llamadas no bloqueantesTemporizadores y manejo de erroresParticularmente, notificar al usuario en caso de demoras ofallas repetidas
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Aplicaciones de monitoreo en espacio de usuario
El monitoreo también ha caído hacia el terreno de lasaplicacionesBrinda mayor flexibilidad
Aunque menos poder
Hay cientos de aplicaciones de monitoreo para todo tipode situacionesUn monitor inteligente, adaptado para un servicio enparticular, puede detectar mejor situaciones anómalas (yno sólo bloqueos)
El SO y los Bloqueos mutuos Prevención Evasión Detección y recuperación La triste realidad. . .
Consideraciones finales
¿Qué es un recurso?No sólo cintas, impresoras, tarjetas de audio. . .¡También segmentos de memoria, tiempo deprocesamiento!¿Y las estructuras lógicas creadas por el SO? Archivos,semáforos, monitores, . . .