Asignatura
Sistema Operativo II
Tema
Concurrencia; Interbloqueos e Inanición
Sustentante
Elías Villalona
Matricula
2019-1378
Maestro
Edison Pérez Ramírez
Fecha
23 de junio del 2020
Concurrencia; Interbloqueos e Inanición
Cuando un proceso de un sistema de multiprogramación espera a que se presente un
evento específico, se dice que se encuentra en un estado de interbloqueo o bloqueo
mutuo. Los procesos que pueden encontrase en esta situación pueden ser uno o varios.
En los sistemas de multiprogramación, compartir recursos es uno de los principales
objetivos del sistema operativo. Cuando se comparten recursos entre una población de
usuarios o procesos, cada uno de los cuales mantiene un control exclusivo sobre ciertos
recursos asignados a él, es posible que se produzcan bloqueos mutuos que impedirán la
terminación de algunos de los procesos del sistema.
El Aplazamiento Indefinido
En cualquier sistema que mantenga los procesos en espera mientras se les asigna un
recurso o se toman decisiones de planificación, la programación de un proceso puede
postergarse indefinidamente mientras otro recibe la atención del sistema. El
aplazamiento indefinido puede ocurrir debido a predisposiciones en las políticas de
planificación de recursos del sistema. En algún momento la prioridad de ese proceso
superará la prioridad de los entrantes y el proceso en espera será atendido.
Casos de Interbloqueos
El caso más simple de interbloqueo sería el de un sólo proceso que espera la
ocurrencia de un evento y, sin embargo, el sistema no incluye la posibilidad de señalar
dicha ocurrencia. Es muy difícil detectar los bloqueos mutuos de esta naturaleza. La
mayor parte de los bloqueos mutuos implican una competencia entre varios procesos
por varios recursos.
El sistema operativo no está obligado a ejecutar los procesos en ningún orden en
particular. En concreto, si la concesión de un recurso a un proceso determinado puede
provocar interbloqueo, el sistema operativo es muy libre de suspender al proceso y no
atender su petición hasta que esté seguro de que esto no conduce a una situación
problemática.
Condiciones para un Interbloqueo
Condición de exclusión mutua: Los procesos exigen un control exclusivo de
los recursos que necesitan.
Condición de espera: Los procesos mantienen la posesión de los recursos ya
asignados a ellos mientras esperan recursos adicionales.
Condición de no apropiación: Los recursos no pueden arrebatarse a los
procesos a los cuales están asignados hasta que termine su utilización.
Condición de espera circular: Existe una cadena circular de procesos en la que
cada proceso tiene uno o más recursos que son requeridos por el siguiente
proceso en la cadena.
Como dichas condiciones son necesarias para que se presente un interbloqueo, la
existencia de un bloqueo mutuo implica que se han dado todas y cada una de las cuatro
condiciones.
Prevención de Interbloqueos
La estrategia empleada con más frecuencia por los diseñadores para tratar el bloqueo
mutuo es la prevención. En esta sección se examinan los métodos de prevención, junto
con los efectos que tienen sobre los usuarios y los sistemas, sobre todo desde la
perspectiva del rendimiento.
Cada proceso deberá pedir todos sus recursos al mismo tiempo y no podrá seguir
la ejecución hasta haberlos recibido todos.
Si a un proceso que tiene recursos se le niegan los demás, ese proceso deberá
liberar sus recursos y, en caso necesario, pedirlos de nuevo junto con los recursos
adicionales.
Se impondrá un ordenamiento lineal de los tipos de recursos en todos los
procesos; es decir, si a un proceso le han sido asignados recursos de un tipo
específico, en lo sucesivo sólo podrá pedir aquellos recursos que siguen en el
ordenamiento.
Negación de la condición de espera
La primera de las estrategias requiere que los recursos que necesita un proceso sean
pedidos de una sola vez. El sistema debe proporcionarlos según el principio de todo o
nada. Si está disponible el conjunto de los recursos que necesita un proceso, entonces el
sistema puede asignarle todos los recursos y éste seguir su ejecución.
Si no está disponible alguno de ellos, el proceso debe esperar. Mientras espera no
puede tener ningún recurso. Con esto se elimina la condición de espera y no puede
ocurrir un interbloqueo.
Negación de la condición de no apropiación
La segunda estrategia de Havender consiste en liberar los recursos que un proceso
tiene asignados cuando se le niegan peticiones de recursos adicionales. De esta forma,
se anula la condición de no apropiación.
Los recursos se pueden quitar al proceso que los tiene antes de que termine su
ejecución. En este caso también existe un costo excesivo. Cuando un proceso libera
recursos puede perder todo el trabajo realizado hasta ese momento.
Negación de la condición de espera circular
La tercera estrategia de Havender anula la posibilidad de un espera circular. Como
todos los recursos tienen una numeración única y como los procesos deben pedir los
recursos en un orden lineal ascendente:
Los recursos deben pedirse en un orden ascendente por número de recursos. El
número de recurso es asignado por la instalación y debe tener un tiempo de vida
largo (meses o años). Si se agregan nuevos tipos de recursos, puede ser necesario
reescribir los programas y los sistemas.
Lógicamente, cuando se asignan los números de recursos, éstos deben reflejar el
orden normal en que los usan la mayoría de las tareas. Pero los procesos que
necesiten los recursos en un orden diferente que el previsto por el sistema, los
deberán adquirir y conservar, quizá durante tiempo antes de utilizarlos realmente,
lo que significa un desperdicio considerable.
Una de las metas más importantes de los sistemas operativos actuales es crear
ambientes amables con el usuario. Los usuarios deben ser capaces de desarrollar
sus aplicaciones sin tener en cuenta molestas restricciones de hardware y
software.
Evitar interbloqueos
Aun presentándose las condiciones para un interbloqueo, todavía es posible evitarlo
mediante una asignación cuidadosa de los recursos. Tal vez el algoritmo más famoso
para evitar el interbloqueo sea el algoritmo del banquero de Dijkstra (73), cuyo
interesante nombre se debe a que atañe a un banquero que otorga préstamos y recibe
pagos a partir de una determinada fuente de capital.
Defectos del algoritmo del banquero
El algoritmo requiere un número fijo de recursos asignables. Como los recursos a
menudo requieren servicio, ya sea por algún fallo o por mantenimiento
preventivo, no se puede contar con que será siempre constante.
El algoritmo requiere una población de usuarios constantes. En los sistemas
multiprogramables y más en los de tiempo compartido, la población de usuarios
cambia constantemente, incluso en cuestión de segundos.
El algoritmo requiere que el banquero satisfaga todas las peticiones en un tiempo
finito. Es evidente que en los sistemas reales esto no es una garantía suficiente.
De manera similar, el algoritmo requiere que los procesos salden sus préstamos
(es decir, devuelvan sus recursos) en un tiempo finito. Una vez más, esto es
insuficiente para un sistema de tiempo real.
Detección y Recuperación de Interbloqueos
La detección del bloqueo mutuo es el proceso de determinar si realmente existe un
interbloqueo e identificar los procesos y recursos implicados en él. Los algoritmos de
detección determinan por lo general si existe una espera circular.
Reducción de las gráficas de asignación de recursos
Una técnica útil para detectar los interbloqueos consiste en ir reduciendo una gráfica
determinando los procesos que pueden completar su ejecución. Si pueden atenderse las
peticiones de recursos de un proceso, se dice que la gráfica puede ser reducida por ese
proceso. Esta reducción es equivalente a mostrar la gráfica como si el proceso hubiese
acabado y hubiera devuelto los recursos al sistema.
Estrategias para Resolver Interbloqueos
Los resultados de la investigación sobre el bloqueo mutuo han sido satisfactorios en
cuanto a que se han encontrado métodos limpios y rápidos para manejar la mayoría de
los problemas más comunes. Existen cuatro áreas de interés relacionadas con los
interbloqueos que pueden resumirse como prevención, técnicas para evitarlos, detección
y recuperación de los mismos.
En la prevención del interbloqueo interesa ajustar el sistema para eliminar toda
posibilidad de que ocurra un bloqueo mutuo. La prevención suele funcionar pero sus
métodos ocasionan, en general, un aprovechamiento pobre de los recursos. No obstante,
estos métodos se utilizan con frecuencia.
Las técnicas que tienen como objetivo evitar el interbloqueo imponen condiciones
menos atractivas que en la prevención, para tratar de obtener un aprovechamiento de los
recursos. No elimina como las técnicas de prevención todas las posibilidades de que se
produzca un bloqueo mutuo, pero se esquiva cuanto está a punto de suceder (algoritmo
del banquero de Dijkstra)
Los métodos de detección del interbloqueo es utilizan en sistemas que permiten la
ocurrencia de los mismos, ya sea de manera voluntaria o involuntaria. Su objetivo es
determinar si ha ocurrido un bloqueo mutuo y saber exactamente cuáles son los
procesos y recursos implicados en él.
Los métodos de recuperación están íntimamente ligados a los de detección. Sirven
para eliminar los interbloqueos detectados en un sistema para poder seguir trabajando y
para que los procesos implicados puedan terminar su ejecución y liberen sus recursos.
La recuperación es un problema complejo, en el mejor de los casos, los sistemas se
recuperan de un bloqueo mutuo eliminando completamente uno o varios de los procesos
implicados.
En los sistemas actuales la recuperación se suele realizar eliminado un proceso y
arrebatándole sus recursos. Por lo general, el proceso eliminado se pierde pero ahora es
posible concluir los procesos restantes.
Reducción de las gráficas de asignación de recursos.
Una técnica útil para detectar los interbloqueos consiste en ir reduciendo una gráfica
determinando los procesos que pueden completar su ejecución. Si pueden atenderse las
peticiones de recursos de un proceso, se dice que la gráfica puede ser reducida por ese
proceso.
Esta reducción es equivalente a mostrar la gráfica como si el proceso hubiese
acabado y hubiera devuelto los recursos al sistema. Si una gráfica puede ser reducida
por todos sus procesos, entonces no hay interbloqueo. Si una gráfica no puede ser
reducida por todos sus procesos, los procesos irreductibles constituyen el conjunto de
procesos en bloqueo mutuo de la gráfica.
Cuando se ha bloqueado un sistema, el interbloqueo debe romperse mediante la
eliminación de una o más de las condiciones necesarias. Por lo general, varios procesos
perderán una parte o la totalidad del trabajo efectuado, pero el precio pagado puede ser
pequeño, en comparación con las consecuencias de permitir que el sistema siga
bloqueado.
Interbloqueos: Sistemas Actuales/Sistemas Futuros
En los sistemas actuales, el interbloqueo se ha considerado generalmente como una
molestia limitada. La mayor parte de los sistemas siguen los métodos básicos de
prevención sugeridos por Havender, y tales métodos parecen ser satisfactorios.
Sin embargo, en los sistemas futuros el bloqueo mutuo será una consideración mucho
más importante por varias razones:
Los sistemas futuros estarán más orientados hacia operaciones asíncronas en
paralelo que hacia las operaciones en serie. El multiprocesamiento es ya muy
común y la computación paralela será dominante así como la proliferación de
redes y sistema distribuidos.
En los sistemas futuros, la asignación tenderá a ser dinámica. Los procesos podrán
adquirir y liberar recursos según sus necesidades. Los usuarios no necesitarán
saber mucho acerca de sus requisitos de recursos antes de la ejecución de un
programa.
Con la creciente tendencia de los diseñadores de sistemas operativos a contemplar
los datos como un recurso más, aumentará notablemente el número de recursos
que debe administrar un sistema operativo.
Por lo tanto, la tarea de asignar recursos sin la posibilidad de interbloqueos en los
sistemas de cómputo recaerá sobre el sistema operativo. Con el abaratamiento y la
creciente potencia de los recursos, es razonable que se amplíen las funciones de la
computadora y del sistema operativo.
