Sistemas operativos modernos

Ahora supongamos que un sistema UNIX tiene 100 ranuras de procesos. Se están ejecu­ tando 10 programas, cada uno de los cuales necesita crear 12 (sub)procesos. Después de que cada proceso ha creado otros nueve, los diez procesos originales y los 90 procesos nuevos ha­ brán saturado la tabla. Ahora cada uno de los diez procesos originales da vueltas en un ciclo infinito, ejecutando llamadas fork y fracasando: un bloqueo irreversible. La probabilidad de que esto suceda es diminuta, pero podría suceder. ¿Debemos abandonar los procesos y la lla­ mada fork para eliminar el problema? El número máximo de archivos abiertos también está limitado por el tamaño de la tabla de nodos-i, por lo que cuando ésta se llena, se presenta un problema similar. El espacio de inter­ cambio en el disco es otro recurso Umitado. De hecho, casi todas las tablas del sistema opera­ tivo representan un recurso finito. ¿Debemos abolirías todas porque podría suceder que cada proceso de un conjunto de n procesos pida 1 /n del total, y luego trate de pedir uno más? Casi todos los sistemas operativos, incluidos UNIX y Windows, simplemente ignoran el problema, bajo la suposición de que la mayoría de los usuarios prefiere un bloqueo irreversible ocasional que una regla que limite a todos los usuarios a tener un solo proceso, un archivo abierto; un solo elemento de cada cosa. Si la eliminación de bloqueos irreversibles no implica­ ra un costo, no habría qué discufir. El problema es que el precio es elevado, sobre todo, desde el punto de vista de imponer restricciones inconvenientes a los procesos, como veremos en bre­ ve. Así, enfrentamos un desagradable equilibrio entre comodidad y corrección, y muchas dis­ cusiones acerca de qué es importante y para quién. En tales condiciones, es difícil hallar soluciones generales. 3.4 DETECCION DE BLOQUEOS IRREVERSIBLES Y RECUPERACIÓN POSTERIOR Una segunda técnica es la detección y la recuperación. Cuando se usa esta técnica, el sistema no intenta prevenir que se presenten bloqueos irreversibles. En vez de eso, deja que se presenten, trata de detectar cuándo suceden y toma medidas para recuperarse después. En esta sección exa­ minaremos algunas formas para detectar bloqueos irreversibles y recuperarse después de ellos. 3.4.1 Detección de bloqueos irreversibles con un recurso de cada tipo Comencemos con el caso más sencillo: sólo hay un recurso de cada tipo. Un sistema con estas condiciones podría tener un escáner, una grabadora de CD, un graficador y una unidad de cinta: no más de un elemento de cada clase de recursos. Dicho de otro modo, por el mo­ mento estamos excluyendo los sistemas que tienen dos impresoras, por ejemplo. Los veremos después, empleando un método distinto. Para un sistema con estas condiciones, podemos construir un grafo de recursos como el que se ilustra en la figura 3-3. Si contiene uno o más ciclos, quiere decir que hay un bloqueo irreversible. Cualquier proceso que forme parte del ciclo habrá caído en un bloqueo irreversible. Si no hay ciclos, tampoco hay bloqueo irreversible.