BLOQUEOS MUTUOS- Silberschatz Galvin

Captulo 7

En un entorno de multiprogramacin, varios procesos podran competir por un nmero finito de recursos. Un proceso solicita recursos; si stos no estn disponibles, el proceso pasa a un estado de espera. Puede suceder que los procesos en espera nunca vuelvan a cambiar de estado, porque los recursos que solicitaron estn en manos de otros procesos que tambin estn esperando. Esta situacin se llama bloqueo mutuo (deadlock), y ya hablamos de ella brevemente en el captulo 6, cuando tratamos los semforos. Tal vez la mejor ilustracin de un bloqueo mutuo sea la que ofrece una ley aprobada por la legislatura de Kansas a principios de siglo. Esta ley rezaba, en parte: "Si dos trenes se aproximan uno al otro en un cruce, ambos harn alto total y ninguno arrancar de nuevo hasta que el otro se haya ido." En este captulo describiremos los mtodos que un sistema operativo puede utilizar para resolver el problema de los bloqueos mutuos. Cabe sealar que la mayor parte de los sistemas operativos actuales no cuenta con mecanismos de prevencin de bloqueos mutuos. Es probable que tales funciones se incorporen en el futuro, a medida que los problemas de bloqueo mutuo se vuelvan ms comunes. Varias tendencias causarn esta situacin, entre ellas el aumento en el nmero de procesos, el aumento en la cantidad de recursos (incluidos procesadores) de los sistemas, y el hincapi en los servidores de archivos y bases de datos de larga vida en lugar de sistemas por lotes.

7.1

Modelo del sistemaUn sistema consiste en un nmero finito de recursos que deben distribuirse entre varios procesos que compiten. Los recursos se dividen en varios tipos, cada uno de los cuales consiste en cierta cantidad de ejemplares idnticos. El espacio de memo-

208

Captulo 7 Bloqueos mutuos

7.2 Caracterizacin de

dar pie a bloqueos mutuos (por ejemplo, el recurso IPC que mencionamos en captulo 4). Para ilustrar un estado de bloqueo mutuo, consideremos un sistema que tiene tres unidades de cinta. Supongamos que hay tres procesos, cada uno de los cuales una de estas unidades de cinta. Si ahora cada proceso solicita otra unidad de cinta, los tres procesos estarn en un estado de bloqueo mutuo; cada uno est esperando el suceso "se libera unidad de cinta", que slo uno de los otros procesos que esperan puede causar. Este ejemplo ilustra un bloqueo mutuo en el que intervienen procesos que compiten por el mismo tipo de recursos. En un bloqueo mutuo tambin pueden estar implicados diferentes tipos de recursos. Por ejemplo, consideremos un sistema que tiene una impresora y una unidad de cinta. Supongamos que el proceso adquiri la unidad de cinta, y el proceso la impresora. Si solicita la impresora y solicita la unidad de cinta, habr un bloqueo mutuo.

ria, los ciclos de CPU, los archivos y los dispositivos de (como impresoras y unidades de cinta) son ejemplos de tipos de recursos. Si un sistema tiene dos CPU, el tipo de recursos CPU tiene dos ejemplares. As mismo, el tipo de recursos impresora podra tener cinco ejemplares. Si un proceso solicita un ejemplar de un tipo de recursos, la asignacin de cualquier ejemplar del tipo satisfar la solicitud. Si no es as, es porque los ejemplares no son idnticos, y no se han definido correctamente las clases de recursos. Por ejemplo, un sistema podra tener dos impresoras, las cuales se pueden definir como pertenecientes a la misma clase de recursos si a nadie le importa cul impresora imprime cules salidas. Sin embargo, si una impresora est en el noveno piso y la otra est en el stano, la gente del noveno piso tal vez no las considere equivalentes, y podra ser necesario definir clases de recursos distintas para cada impresora. Un proceso debe solicitar un recurso antes de usarlo, y debe liberarlo despus de usarlo. Un proceso puede solicitar tantos recursos como necesite para realizar la tarea designada. Obviamente, el nmero de recursos solicitados no puede exceder el nmero total de recursos con que el sistema cuenta. Dicho de otro modo, un proceso no puede solicitar tres impresoras si el slo tiene dos. En el modo de funcionamiento normal, un proceso slo puede utilizar un recurso siguiendo esta secuencia:

Caracterizacin de bloqueos mutuosDebe ser obvio que los bloqueos mutuos son indeseables. En un bloqueo mutuo, los procesos nunca terminan su ejecucin y los recursos del sistema quedan acaparados, lo que impide que otros trabajos puedan comenzar. Antes de estudiar los diferentes mtodos para manejar el problema del bloqueo mutuo, describiremos los rasgos que caracterizan a los bloqueos mutuos.

1. Solicitud: Si la solicitud no puede atenderse de inmediato (por ejemplo, si otro proceso est usando el recurso), el proceso solicitante deber esperar hasta que pueda adquirir el recurso. 2. Uso: El proceso puede operar con el recurso (por ejemplo, si el recurso es una impresora, el proceso puede imprimir en la impresora). 3. Liberacin: El proceso libera el recurso.

7.2.1 Condiciones necesariasPuede surgir una situacin de bloqueo mutuo en un sistema si se cuniplen simultneamente las cuatro condiciones siguientes: Mutua Exclusin: Al menos un recurso debe adquirirse de modo que no pueda compartirse; es decir, slo un proceso a la vez podr usar ese recurso. Si otro proceso solicita ese recurso, el proceso solicitante deber esperar hasta que se haya liberado el recurso. 2. Retener y esperar: Debe existir un proceso que haya adquirido al menos un recurso y est esperando para adquirir recursos adicionales que ya han sido asignados a otros procesos. 3. No expropiacin: Los recursos no se pueden arrebatar; es decir, la liberacin de un recurso siempre es voluntaria por parte del proceso que lo adquiri, una vez que ha terminado su tarea. de procesos en espera tal 4. Espera circular: Debe existir un conjunto est esperando un que est esperando un recurso que fue adquirido por est esperando un recurso que fue adrecurso que fue adquirido por quirido por y est esperando un recurso que fue adquirido por

La solicitud y liberacin del recurso son llamadas al sistema, como se explic en el captulo 3. Ejemplos de tales llamadas son las de solicitar y liberar dispositivo, abrir y cerrar archivo, y asignar y liberar memoria. La solicitud y liberacin y seal con sede otros recursos puede efectuarse mediante las operaciones mforos. Por tanto, para cada uso, el sistema operativo verifica que el proceso usuario haya solicitado el recurso y se le haya asignado. Una tabla del sistema registra si cada recurso est libre o asignado y, si un recurso est asignado, a cul proceso se asign. Si un proceso solicita un recurso que actualmente est asignado a otro proceso, se le puede colocar en una cola de procesos que esperan ese recurso. Un conjunto de procesos est en un estado de bloqueo mutuo si cada uno de los procesos del conjunto est esperando un suceso que slo otro proceso del conjunto puede causar. Los sucesos que ms nos interesan aqu la adquisicin y liberacin de recursos. Los recursos pueden ser fsicos (como impresoras, unidades de cinta, espacio de memoria y ciclos de CPU) o lgicos (por ejemplo, archivos, semforos y monitores). Adems, hay otros tipos de sucesos que podran

210


7.2 Caracterizacin de bloqueos mutuos

Hacemos hincapi en que se deben cumplir las cuatro condiciones para que ocurran bloqueos mutuos. La condicin de espera circular implica la condicin de retener y esperar, as que las cuatro condiciones no son del todo independientes. No obstante, es til considerar cada condicin por separado, como veremos en la seccin 7.4.

7.2.2 Grafo de asignacin de recursos

Figura 7.1 Grafo de asignacin de recursos.

Estados de procesos: El proceso tiene un ejemplar del tipo de recursos y est esperando un ejemplar del tipo de recursos El proceso tiene un ejemplar de y y est esperando un ejemplar del tipo de recursos El proceso tiene un ejemplar del recurso

Los bloqueos mutuos se pueden describir con mayor precisin en trminos de un grafo dirigido llamado grafo de asignacin de recursos del sistema. Este grafo consiste en un conjunto de vrtices V y un conjunto de aristas E. El conjunto V se divide en dos tipos de distintos: = el conjunto de todos los procesos activos del sistema, y = el conjunto de todos los tipos de recursos del sistema. Una arista dirigida del proceso al tipo de recursos R denotada por R ca que el proceso solicit un recurso del tipo y est esperndolo. Una arista dirigida del tipo de recursos al proceso denotada por 1 indica que un plar del tipo de recursos 1 se asign al proceso Una arista dirigida es una arista de solicitud; una es una arista de asignacin. Grficamente, representamos cada proceso con un crculo, y cada tipo de recurso con un cuadrado. Puesto que el tipo de recursos puede tener ms de un 1 1 ejemplar, representamos cada ejemplar como un punto dentro del cuadrado. Cabe sealar que una arista de solicitud slo apunta al cuadrado R mientras que una arista de asignacin tambin debe designar uno de los puntos que estn dentro del cuadrado. Cuando el proceso solicita u n ejemplar del tipo de recursos se inserta una ta de solicitud en el grafo de asignacin de recursos. En el momento en que dicha solicitud puede satisfacerse, la arista de solicitud se transforma instantneamente en una arista de asignacin. Cuando el proceso ya no necesita acceder al recurso, lo libera y la arista de asignacin se borra. El grafo de asignacin de recursos que se muestra en la figura 7.1 representa la situacin siguiente:

Los conjuntos P, R y E:

Ejemplares de recursos:

Un ejemplar del tipo de recursos Dos ejemplares del tipo de recursos Un ejemplar del tipo de recursos Tres ejemplares del tipo de recursos

Dada la definicin de grafo de asignacin de recursos, se puede demostrar que, si el grafo no contiene ciclos, ningn proceso del sistema estar en bloqueo mutuo. Por otro lado, si el grafo contiene un ciclo, podra existir un bloqueo mutuo. Si cada tipo de recursos tiene exactamente un ejemplar, un ciclo implica que ha ocurrido un bloqueo mutuo. Si en el ciclo interviene slo un conjunto de tipos de recursos, cada uno de los cuales slo tiene un ejemplar, hay un bloqueo mutuo. Cada uno de los procesos que intervienen en el ciclo est en bloqueo mutuo. En este caso, un ciclo en el grafo es condicin necesaria y suficiente para la existencia de un bloqueo mutuo. Si cada tipo de recursos tiene varios ejemplares, un ciclo no necesariamente implica que ha ocurrido un bloqueo mutuo. En este caso, un ciclo en el grafo es una condicin necesaria pero no suficiente para la existencia de un bloqueo mutuo. Para ilustrar este concepto, regresemos al grafo de asignacin de recursos que se muestra en la figura 7.1. Supongamos que el proceso solicita un ejemplar del tipo de recursos Dado que actualmente no hay ningn ejemplar de ese recurso disponible, se aade una arista de solicitud al grafo (Fig. 7.2). En este momento, hay dos ciclos mnimos en el sistema:

212


7.3 Mtodos para manejar bloqueos mutuos

Figura 7.2 Grafo de asignacin de recursos con bloqueo mutuo.

Figura 7.3 Grafo de asignacin de recursos con un ciclo pero sin bloqueo mutuo.

y estn en bloqueo mutuo. El proceso est esperando el Los procesos recurso que fue adquirido por el proceso ste, a su vez, est esperando que el proceso o el proceso libere el recurso Adems, el proceso est esperando que el proceso libere el recurso Consideremos ahora el grafo de asignacin de recursos de la figura 7.3. En este ejemplo, tambin tenemos un ciclo:

Sin embargo, no hay bloqueo mutuo. Observe que el proceso podra liberar su ejemplar del tipo de recursos Entonces, ese recurso podra asignarse a lo que rompera el ciclo. En sntesis, si un grafo de asignacin de recursos no tiene ciclos, el sistema no est en estado de bloqueo mutuo. Por otra parte, si hay un ciclo, el sistema podra o no estar en bloqueo mutuo. Esta observacin es importante para manejar el problema del bloqueo mutuo.

Mtodos para manejar bloqueos mutuos

Hay tres mtodos principales para enfrentar el problema del bloqueo mutuo:

Podemos usar un protocolo que asegure que el sistema llegar a un estado de bloqueo mutuo. Podemos permitir que el sistema entre en bloqueo mutuo y luego se recupere. Podemos desentendernos del problema y hacer como si nunca ocurrieran bloqueos mutuos en el sistema. Esta solucin es la que adopta la mayor parte de los sistemas operativos, incluido UNIX.

Profundizaremos un poco ms en cada mtodo. Luego, en las secciones 7.4 a 7.8, presentaremos algoritmos detallados. Para asegurar que nunca ocurran bloqueos mutuos, el sistema puede usar un esquema de prevencin de bloqueos mutuos o bien uno de evitacin de bloqueos mutuos. La prevencin de bloqueos mutuos es una serie de mtodos que garantizan que al menos una de las condiciones necesarias 7.2.1) no podr cumplirse. Estos mtodos previenen los bloqueos mutuos restringiendo la forma de hacer solicitudes de recursos. Analizaremos estos mtodos en la seccin 7.4. La evitacin de bloqueos mutuos, en cambio, requiere proporcionar al sistema operativo informacin anticipada acerca de los recursos que un proceso va a solicitar y usar durante su existencia. Con esta informacin adicional, podemos decidir, para cada solicitud, si el proceso debe esperar o no. Cada solicitud obliga al sistema a considerar los recursos que estn disponibles, los que estn asignados a cada proceso, y las futuras solicitudes y liberaciones de cada proceso, antes de decidir si la solicitud en curso se puede satisfacer o debe diferirse. Estudiaremos estos esquemas en la seccin 7.5. Si un sistema no utiliza un algoritmo de prevencin de bloqueos mutuos, ni uno de evitacin de bloqueos mutuos, puede ocurrir una situacin de bloqueo mutuo. En este entorno, el sistema podra contar con un algoritmo que examina el estado del sistema para determinar si ha ocurrido un bloqueo mutuo, y otro para recuperarse de tal situacin, en caso de presentarse. Examinaremos estas cuestiones en las secciones 7.6 y 7.7. Si un sistema no se asegura de que nunca ocurrirn bloqueos mutuos, y tampoco cuenta con un mecanismo para detectar los bloqueos mutuos y recuperarse de ellos, podramos encontrarnos en una situacin en la que el sistema est en un estado de bloqueo mutuo y no tiene manera de darse cuenta de lo que ha sucedido. En tal caso, el bloqueo mutuo no detectado causar el deterioro del desempeo del sistema, porque procesos que no pueden ejecutarse estn reteniendo recursos, y porque cada vez ms procesos, a medida que solicitan recursos, entran en un

214


7.4 Prevencin de bloqueos mutuos

215

do de bloqueo mutuo. Tarde o temprano, el sistema dejar de funcionar y tendr que reiniciarse manualmente. Aunque este mtodo no parece ser una estrategia viable para enfrentar el problema del bloqueo mutuo, es el que se usa en algunos sistemas operativos. En muchos sistemas, los bloqueos mutuos son muy poco frecuentes (digamos, uno al ao); por ello, es ms econmico utilizar este mtodo en lugar de los mtodos ms costosos de prevencin, evitacin, deteccin y recuperacin de bloqueos mutuos que deben emplearse constantemente. Adems, hay circunstancias en las que el sistema est "congelado" sin que haya un bloqueo mutuo. Como ejemplo de esta situacin, consideremos un proceso de tiempo real que se ejecuta con la prioridad ms alta (o cualquier proceso que se ejecuta con un planificador no expropiativo) y nunca devuelve el control al sistema operativo.

7.4

Prevencin de bloqueos mutuos

Como sealamos en la seccin 7.2.1, para que ocurra un bloqueo mutuo se deben cumplir las cuatro condiciones necesarias. Si aseguramos que al menos una de estas condiciones no pueda cumplirse, podremos prevenir la ocurrencia de bloqueos mutuos. Profundicemos en este enfoque examinando por separado cada una de las cuatro condiciones necesarias.

7.4.1 Mutua Exclusin

solicitar recursos adicionales tendr que liberar todos los que tiene asignados. Para ilustrar la diferencia entre estos dos protocolos, consideremos un proceso que copia datos de una unidad de cinta a un archivo en disco, ordena el archivo disco y luego imprime los resultados en una impresora. Si todos los recursos deben solicitarse en momento en que un proceso inicia su ejecucin, el proceso deber solicitar desde un principio la unidad de cinta, el archivo de disco y la impresora, y retendr la impresora durante toda su ejecucin, aunque slo la vaya a necesitar al final. El segundo mtodo permite al proceso solicitar inicialmente slo la unidad de cinta y el archivo de disco. El proceso copia de la cinta al disco, y luego libera ambos recursos. Luego, el proceso debe solicitar otra vez el archivo de disco, y la impresora. Despus de copiar el archivo de disco en la impresora, el proceso libera estos dos recursos y termina. Estos protocolos tienen dos desventajas principales. En primer lugar, la utilizacin de los recursos podra ser baja, ya que muchos de los recursos podran estar asignados pero sin usarse durante periodos largos. En el ejemplo dado, slo podramos liberar la unidad de cinta y el archivo de disco, y luego solicitar otra vez el archivo de disco y la impresora, si podemos estar seguros de que nuestros datos permanecen en el archivo de disco. Si no se nos puede garantizar esto, deberemos solicitar todos los recursos al principio si usamos cualquiera de estos dos protocolos. En segundo lugar, puede haber inanicin. Un proceso que necesite varios recursos muy solicitados podra tener que esperar indefinidamente porque al menos uno de los recursos que necesita siempre est asignado a algn otro proceso.

Se debe cumplir la condicin de mutua exclusin para los recursos no compartibles. Por ejemplo, dos o ms procesos no pueden compartir una impresora. Los recursos compartibles, en cambio, no requieren acceso mutuamente exclusivo, y por tanto no pueden intervenir en un bloqueo mutuo. Los archivos slo de lectura son un buen ejemplo de recurso compartible. Si varios procesos intentan abrir un archivo slo de lectura al mismo tiempo, se les podr conceder acceso simultneo al archivo. Un proceso nunca necesita esperar un recurso compartible. Sin embargo, generalmente no es posible prevenir los bloqueos mutuos negando la condicin de mutua exclusin; algunos recursos son intrnsecamente no compartibles.

7.4.3 No expropiacin

7.4.2 Retener y esperar

Para asegurar que la condicin de retener y esperar nunca ocurra en el sistema, debemos garantizar que, siempre que un proceso solicite un recurso, no retenga ningn otro recurso. Un protocolo que puede usarse obliga a cada proceso a solicitar y recibir todos sus recursos antes de iniciar su ejecucin. Podemos implementar esta medida exigiendo que las llamadas al sistema que solicitan recursos para un proceso precedan a todas las dems llamadas al sistema. Un protocolo alternativo permite a un proceso solicitar recursos slo cuando no tiene ninguno. Un proceso puede solicitar recursos y utilizarlos, pero antes de que

La tercera condicin necesaria es que no haya expropiacin de recursos que ya se hayan asignado. Para asegurar que esta condicin no se cumpla, podemos usar el protocolo siguiente. Si un proceso que tiene algunos recursos solicita otro que no se le puede asignar de inmediato (es decir, si el proceso debe esperar), entonces todos los recursos que actualmente tiene se liberarn implcitamente. Los recursos expropiados se aadirn a la lista de recursos que el proceso est esperando, y este ltimo slo se reiniciar cuando pueda recuperar sus antiguos recursos y los nuevos que est solicitando. Como alternativa, si un proceso solicita algunos recursos, primero se comprueba que estn disponibles. Si as es, los recursos se asignan; si no, se determina si estn asignados a algn otro proceso que est esperando recursos adicionales. Si se es el caso, se le quitan los recursos deseados al proceso que est esperando y se le asignan al que los solicit. Si los recursos no estn disponibles ni estn siendo retenidos por un proceso que espera, el proceso solicitante deber esperar. Mientras el proceso espera, podra ser despojado de sus recursos, pero slo si otro proceso los solicita. Un proceso slo puede reiniciarse si ya se le han asignado los recursos nuevos que solicit y si recuper cualesquier recursos que haya perdido mientras esperaba.

216


7.5

Evitacin de bloqueos mutuos

217

Este protocolose aplica a menudo a recursos cuyo estado se puede guardar fcilmente y despus restaurarse, como registros de CPU y espacio de memoria; generalmente no puede aplicarse a recursos tales como impresoras y unidades de cinta.

7.5


7.4.4 Espera circular

Una forma de asegurar que la condicin de espera circular nunca se cumpla es imponer un ordenamiento total de todos los tipos de recursos, y exigir que cada proceso solicite recursos en orden creciente de enumeracin. R,) el conjunto de tipos de recursos. Asignamos a cada tipo Sea R = un nmero entero nico que nos permite comparar dos recursos y determinar si uno precede al otro en nuestro ordenamiento. En trminos formales, definimos una N, donde N es el conjunto de nmeros naturales. Por funcin uno a uno F: R ejemplo, si el conjunto de tipos de recursos R incluye unidades de cinta, unidades de disco e impresoras, la funcin podra definirse as:

de cinta) = 1, de disco) = 5, = 12.

Los algoritmos de prevencin de bloqueos mutuos, como vimos en la seccin 7.4, basan en restringir la forma de hacer solicitudes. Las restricciones aseguran que menos una de las condiciones necesarias para el bloqueo mutuo no podr ocurrir, por ende que no podr haber bloqueos mutuos. Sin embargo, los posibles efectos secundarios de la prevencin de bloqueos mutuos empleando estos mtodos son un bajo aprovechamiento de los recursos y una reduccin del rendimiento del sistema. Un mtodo alternativo para evitar los bloqueos mutuos es pedir informacin adicional acerca de la forma en que se solicitarn los recursos. ejemplo, en un sistema que tiene una unidad de cinta y una impresora, se nos podra decir que el proceso solicitar primero la unidad de cinta, y luego la impresora, antes de liberar ambos recursos. El proceso Q, en cambio, solicitar primero la impresora y luego la unidad de cinta. Con este conocimiento de la secuencia completa de solicitudes y liberaciones para cada proceso, podemos decidir, para cada solicitud, si el proceso debe esperar o no. Cada solicitud obliga al sistema a considerar los recursos que estn disponibles en ese momento, los que ya se asignaron a cada proceso, y las solicitudes y liberaciones futuras de cada proceso, para decidir si la solicitud en curso se puede satisfacer o debe esperar con el fin de evitar un posible bloqueo mutuo futuro. requeLos distintos algoritmos difieren en la cantidad y el tipo de la rida. El modelo ms til y sencillo obliga a cada proceso a declarar el de recursos de cada tipo que podra necesitar.Si tenemos informacin yriori acerca del nmero mximo de recursos de cada tipo que cada proceso podra solicitar, podremos construir un algoritmo que asegure que el sistema nunca estar un estado de bloqueo mutuo. Este algoritmo define la estrategia de de mutuos. Un algoritmo de evitacin de bloqueos mutuos examina dinmicamente el estado de asignacin de recursos para asegurar que nunca pueda haber una condicin de espera circular. El de asignacin de recursos est definido por el nmero de recursos disponibles y asignados, y las demandas mximas de los procesos.

7.5.1 Estado seguroUn estado es si el sistema puede asignar recursos a cada proceso (hasta su mximo) en algn orden y aun as evitar los bloqueos mutuos. En trminos ms formales, un sistema est en un estado seguro slo si existe una secuencia segura. Una es una secuencia segura para el estado de asigsecuencia de procesos nacin actual si, para cada los recursos que todava puede solicitar se pueden satisfacer con los recursos que actualmente estn disponibles ms los recursos que tienen todos los donde i. En esta situacin, si los recursos que el proceso necesita no estn inmediatamente disponibles, podr esperar hasta que todos los hayan terminado. En ese momento, podr obtener todos los recursos que sita, llevar a cabo su tarea designada, liberar los recursos que adquiri y terminar. puede obtener los recursos que necesita, y as sucesivamenCuando termina, te. Si no existe tal secuencia, se dice que el estado del sistema es inseguro.

Ahora podemos considerar el siguiente protocolo para prevenir bloqueos mutuos: un proceso slo puede solicitar recursos en orden de enumeracin creciente. Es decir, un proceso puede solicitar inicialmente cualquier cantidad de ejemplares Despus, el proceso podr solicitar ejemplares de un tipo de recursos, digamos Si se requieren varios ejemplares del del tipo de recursos si y slo si mismo tipo de recursos, se deber emitir una sola solicitud que los incluya todos. Por ejemplo, empleando la funcin que acabamos de definir, un proceso que desee usar la unidad de cinta y la impresora al mismo tiempo deber solicitar primero la unidad de cinta y luego la impresora. Como alternativa, podemos exigir que, siempre que un proceso solicite un ejemplar del tipo recursos R haya liberado cualesquier recursos que tenga, tales que F(R Si se usan estos dos protocolos, la condicin de espera circular no podr cumplirse. Podemos demostrar esto suponiendo que existe una espera circular el conjunto de procesos que in(demostracin por contradiccin). Sea tervienen en la espera circular, donde est esperando un recurso el cual fue (Utilizamos aritmtica de mdulo con los subndices, adquirido por el proceso est esperando un recurso que fue adquirido por Entonde manera que ces, puesto que el proceso est reteniendo el recurso y solicitando el recurso debe cumplirse que para todo i. Sin embargo, esta condicin ... Por transitividad, lo implica que cual es imposible. Por tanto, no puede haber espera circular. Cabe sealar que la funcin F debe definirse segn el orden de uso normal de los recursos de un sistema. Por ejemplo, dado que la unidad de cinta por lo regular se necesita antes que la impresora, sera razonable definir de cinta)

218


7.5


219

Figura 7.4 Espacios de estados seguros, inseguros y de bloqueo mutuo.

dr cuatro unidades disponibles. Puesto que el proceso tiene cinco unidades, pero tiene un mximo de 10, podra solicitar entonces cinco unidades ms. Dado que no hay tantas unidades disponibles, el proceso tendra que esperar. As mismo, el proceso podra solicitar otras seis unidades de cinta y tener que esperar, lo que dara pie a un bloqueo mutuo. Nuestro error fue conceder la unidad de cinta adicional que el proceso solicit. Si hubiramos hecho que esperara hasta que cualquiera de los otros procesos hubiera terminado y liberado sus recursos, podramos haber evitado la situacin de bloqueo mutuo. Dado el concepto de estado seguro, podemos definir algoritmos de evitacin que aseguren que el sistema nunca entrar en un bloqueo mutuo. La idea es simplemente asegurar que el sistema siempre permanecer en un estado seguro. Inicialmente, el sistema est en un estado seguro. Cada vez que un proceso solicita un recurso que est disponible, el sistema debe decidir si es posible asignar el recurso de inmediato o si el proceso debe esperar. La solicitud slo se atiende si la asignacin deja el sistema en un estado seguro. Cabe sealar que, en este esquema, si un proceso solicita un recurso que est disponible, cabe la posibilidad de que tenga que esperar. Por ello, la utilizacin de recursos podra ser menor de lo que sera sin un algoritmo de evitacin de bloqueos mutuos.

Un estado seguro no es un estado de bloqueo mutuo. Por otra parte, un estado de bloqueo mutuo es un estado inseguro, pero no todos los estados inseguros son bloqueos mutuos (Fig. 7.4). Un estado inseguro podra dar lugar a un bloqueo mutuo. En tanto el estado sea seguro, el sistema operativo podr evitar los estados inseguros (y los bloqueos mutuos). En un estado inseguro, el sistema operativo no puede impedir que los procesos soliciten recursos de tal manera que ocurra un bloqueo mutuo: el comportamiento de los procesos controla los estados inseguros. Como ilustracin, consideremos un sistema que tiene 12 unidades de cinta magntica y tres procesos: y El proceso requiere 10 unidades de cinta, el proceso podra necesitar hasta cuatro unidades, y el proceso podra necesitar el proceso tiene cinhasta nueve unidades. Supongamos que, en el instante co unidades de cinta, tiene dos y tiene dos. (Por tanto, hay tres unidades de cinta libres.) Necesidades actuales

7.5.2 Algoritmo de grafo de asignacin de recursos

Necesidades mximas

En el instante el sistema est en un estado seguro. La secuencia satisface la condicin de seguridad, ya que es posible asignar de inmediato a todas las unidades de cinta que necesitar y que luego liberar (el sistema tendr entonces cinco unidades disponibles); luego el proceso podr obtener todas sus unidades de cinta y devolverlas (el sistema tendr entonces 10 unidades disponibles). Finalmente, el proceso podr obtener todas sus unidades de cinta y devolverlas (el sistema tendr entonces todas sus 12 unidades de cinta disponibles). Observe que es posible pasar de un estado seguro a uno inseguro. Suponga que, en el instante el proceso solicita otra unidad de cinta, la cual le es asignada. El sistema ya no est en un estado seguro. En este punto, slo podremos asignar todas sus unidades de cinta al proceso Cuando ste las devuelva, el sistema slo

Si tenemos un sistema de asignacin de recursos con un solo ejemplar de cada tipo de recursos, podemos usar una variante del grafo de asignacin de recursos que definimos en la seccin 7.2.2 para evitar los bloqueos mutuos. Adems de las aristas de solicitud y asignacin, introducimos un nuevo tipo de arista, llamada arista de reserva. Una arista de reserva indica que el proceso podra solicitar el recurso en algn instante futuro. Esta arista se parece a una de solicitud en cuanto a su direccin, pero se representa con una lnea discontinua. Cuando el proceso solicita el recurso la arista de reserva se te en una de solicitud. As mismo, cuando libera un recurso la arista de asignacin se vuelve a convertir en una arista de reserva Cabe alar que los recursos deben reservarse a priori en el sistema; es decir, antes que el proceso inicie su ejecucin todas sus aristas de reserva debern aparecer ya en el grafo de asignacin de recursos. Podemos relajar esta condicin permitiendo la adicin de una arista de reserva al grafo slo si todas las aristas asociadas al proceso son aristas de reserva. Supongamos que el proceso solicita el recurso R La solicitud slo puede facerse si la conversin de la arista de solicitud en una arista de asignacin no da pie a un ciclo en el grafo de asignacin de recursos. Observe que vela seguridad empleando un algoritmo de deteccin de ciclos. En un grafo de este tipo, semejante algoritmo requiere del orden de n 2 operaciones, donde es el nmero de procesos del sistema. Si no existe ningn ciclo, la asignacin del recurso dejar el sistema en un estado seguro. Si se encuentra un ciclo, la asignacin llevar el sistema a un estado

220


7.5 Evitacin de bloqueos mutuos

Figura 7.5

de asignacin de recursos para evitacin de bloqueos mutuos

Figura 7.6 Estado inseguro en un grafo de asignacin de recursos.

inseguro. tal caso, el proceso tendra que esperar para recibir los recursos que solicit. Para ilustrar este algoritmo, consideremos el grafo de asignacin de recursos de la figura 7.5. Supongamos que solicita Aunque de momento est libre, no podemos asignrselo a porque tal accin creara un ciclo en el grafo (Fig. 7.6). Un ciclo indica que el sistenia est en estado inseguro. Si solicita y solicita ocurrir un bloqueo mutuo.=

Mx: Una matriz m define la demanda mxima de cada proceso. Si k, el proceso puede solicitar cuando ms k ejemplares del tipo de recursos Asignacin: Una matriz m define el nmero de recursos de cada tipo que se han asignado actualmente a cada proceso. Si = k, el proceso tiene asignados actualmente k ejemplares del tipo de recursos R Necesidad: Una matriz m indica los recursos que todava le hacen falta a cada proceso. Si = k, el proceso podra necesitar k ejemplares ms del tipo de recursos para llevar a cabo su tarea. Observe que =

Las estructuras de datos anteriores varan con el tiempo, tanto en tamao como en valor. Para simplificar la presentacin del algoritmo del banquero, establezcamos una notacin. Sean X y Y vectores con longitud n. Decimos que X Y si y slo si para toda i 1, 2, Por ejemplo, si X = yY = entonces Y Podemos tratar cada fila de las matrices Asignacin y Necesidad como vectores y referirnos a ellas como Asignacini y Necesidad, respectivamente. El vector especifica los recursos que actualmente estn asignados al proceso el vector Necesidadi especifica los recursos adicionales que el proceso todava podra solicitar para llevar a cabo su tarea.

Algoritmo del banquero

7.5.3.1 Algoritmo de seguridadEl algoritmo para averiguar si un sistema est o no en un estado seguro se puede describir como sigue:1. Sean Trabajo y Fin vectores con longitud m y n, respectivamente. Asignar los valores iniciales Trabajo := Disponible y := false para i = l, 2, ..., n. 2. Buscar una tal que a. = false, y b. Necesidadi Trabajo

El grafo de asignacin de recursos no puede aplicarse a un de asignacinde recursos con de de recursos. El algoritmo de evitacin de recursos que describiremos a continuacin puede aplicarse a tal sistema, pero es menos eficiente que el esquema de grafo de asignacin de recursos. Dicho algoritmo se conoce como Se escogi este nombre porque el algoritmo podra usarse en un sistema para asegurar que el banco nunca asigne su efectivo disponible de tal manera que ya no pueda satisfacer las necesidades de todos sus clientes. Cuando un proceso nuevo ingresa en el sistema, debe declarar el nmero mximo de ejemplares de cada tipo de recursos que podra necesitar. Este nmero no puede exceder el total de recursos del sistema. Cuando un usuario solicita un conjunto de recursos, el sistema debe determinar si la asignacin de esos recursos dejara el sistema en un estado seguro. Si as es, los recursos se asignan; si no, el proceso deber esperar hasta que otro libere los recursos suficientes. Hay que mantener varias estructuras de datos para implementar el algoritmo del banquero. Dichas estructuras codifican el estado del sistema de asignacin de recursos. Sea el nmero de procesos del sistema, y m, el nmero de tipos de recursos. Necesitamos las siguientes estructuras de datos:

Un vector de longitud m indica el nmero de recursos disponibles de cada tipo. Si = k, hay ejemplares disponibles del tipo de recursos R

222

Captulo

Bloqueos mutuos

7.6 Deteccin de bloqueos mutuos

223

res. Supongamos que, en el instante se tom la siguiente instantnea del sistema: El contenido de la matriz Necesidad se define como Mx - Asignacin y es Necesidad

Si no existe tal continuar con el paso 4. 3. Trabajo := Trabajo + := true ir al paso 2. 4. Si = true para toda i, el sistema est en un estado seguro. n 2 operaciones para decidir si un

Este algoritmo podra requerir del orden de m estado es seguro o no.

7.5.3.2Algoritmo de solicitud de recursosDecimos que el sistema est en un estado seguro. Efectivamente, la secuencia satisface los criterios de seguridad. solicita un ejemplar adicional del tipo de Supongamos ahora que el proceso recursos A y dos ejemplares del tipo de recursos C, de modo que Solicitudl = Para decidir si esta solicitud se puede satisfacer de inmediato, primero verificamos que Solicitudl Disponible (esto es, que lo cual es cierto. Ahora simulamos que la solicitud se atendi, y llegamos al estado nuevo siguiente: Necesidad ABC 302 302 211 002 ABC 743 020 6O0 431 Disponible A BC 230

Sea el vector de solicitudes del proceso Si = k, el proceso quiere ejemplares del tipo de recursos Cuando solicita recursos, se emprenden las acciones siguientes:

Si Solicitudi Necesidadi, ir al paso 2. En caso contrario, indicar una condicin de error, pues el proceso ha excedido su reserva mxima. 2. Si Solicitudi Disponible, ir al paso 3. En caso contrario, deber esperar, ya que los recursos no estn disponibles. 3. Hacer que el sistema simule haber asignado al proceso los recursos que solicit modificando el estado como sigue:

Disponible := Disponible - Solicitudi; := + Solicitudi; Necesidadi := - Solicitudi;

el estado de asignacin de recursos resultante es seguro, la transaccin se llevar a cabo y se asignarn los recursos al proceso pero si el nuevo estado es tendr que esperar y se restaurar el antiguo estado de inseguro, asignacin de recursos.

7.5.3.3 Ejemplo ilustrativo

Consideremos un sistema con cinco procesos, a y tres tipos de recursos A, B y C. El tipo de recursos A tiene 10 ejemplares, tiene 5 ejemplares y C tiene 7 ejempla-

Debemos determinar si este nuevo estado del sistema es seguro. Para ello, ejecutamos nuestro algoritmo de seguridad y averiguamos que la secuencia satisface nuestro requisito de seguridad. Por consiguiente, podemos atender de inmediato la solicitud del proceso No obstante, debe quedar claro que cuando el sistema est en el estado anterior, hecha por ya que los recursos no esno es posible satisfacer una solicitud tn disponibles. Tampoco puede atenderse una solicitud hecha por a pesar de que los recursos estn disponibles, porque el estado resultante no es seguro.

ABC

ABC 332

200 302 211 002

ABC 753 322 9O2 222 433

7.6

Deteccin de bloqueos mutuosSi un sistema no emplea un algoritmo de prevencin de bloqueos mutuos, ni uno de evitacin de bloqueos mutuos, podra presentarse una situacin de bloqueo mutuo. En un entorno as, el sistema debe ofrecer:

224

Captulo 7 Bloqueos mutuos Deteccin de bloqueos

Un algoritmo que examine el estado del sistema y determine si ha ocurrido un bloqueo mutuo Un algoritmo para recuperarse del bloqueo mutuo

En la explicacin que sigue examinaremos ms de cerca estos dos requisitos y su importancia en sistemas que tienen tanto un solo ejemplar de cada tipo de recursos como varios ejemplares de cada tipo de recursos, pero antes de hacerlo debemos sealar que un esquema de deteccin y recuperacin requiere un gasto extra que incluye no slo los costos en tiempo de ejecucin de mantener la informacin necesaria y ejecutar el algoritmo de deteccin, sino tambin las prdidas potenciales inherentes a la recuperacin despus de un bloqueo mutuo.

7.6.1 Un solo ejemplar de cada tipo de recursos

Figura 7.7 (a) Grafo de asignacin de recursos. (b) Grafo de espera correspondiente.

Si todos los tipos de recursos tienen nicamente un ejemplar, podemos definir un algoritmo de deteccin de bloqueos mutuos que utiliza una variante del grafo de asignacin de recursos, llamada grafo de espera. Obtenemos este grafo a partir del de tipo de recursos y uniengrafo de asignacin de recursos eliminando los do las aristas apropiadas. En trminos ms precisos, una arista de a 1 en un grafo de espera implica que el proceso est esperando que el proceso libere un recurso que necesita. Hay una arista en un grafo de espera si y slo si el grafo de asignacin de 1 sos correspondiente contiene dos aristas R4 y R 4 1 para algn recurso R Por ejemplo, en la figura 7.7 presentamos un grafo de asignacin de recursos y el de espera correspondiente. Igual que antes, existe un bloqueo mutuo en el sistema si y slo si el grafo de espera contiene un ciclo. Para detectar los bloqueos mutuos, el sistema necesita mantener el grafo de espera e invocar peridicamente un algoritmo que busque ciclos en el grafo. Un algoritmo para detectar un ciclo en un grafo requiere del orden de operaciones, donde n es el nmero de vrtices del grafo.

Asignacin: Una matriz n m define el nmero de recursos de cada tipo que ya se han asignado a cada proceso. Solicitud: Una matriz n m indica la solicitud actual de cada proceso. Si = k, el proceso est solicitando k ejemplares adicionales del tipo de recursos RLa relacin "menor que" entre dos vectores se define igual que en la seccin 7.5.3. Para simplificar la notacin, trataremos otra vez las filas de las matrices Asignacin y Solicitud como vectores, y nos referiremos a ellos como Asignacini y Solicitudi, respectivamente. El algoritmo de deteccin que describimos aqu simplemente investiga todas las posibles secuencias de asignacin para los procesos que todava no se llevan a cabo. Compare este algoritmo con el del 7.5.3). banquero

7.6.2 Varios ejemplares de un tipo de recursos

El esquema de grafos de espera no es aplicable a un sistema de asignacin de recursos en el que hay mltiples ejemplares de cada tipo de recursos. El algoritmo de deteccin de bloqueos mutuos que describimos a continuacin puede aplicarse a esta clase de sistemas, y utiliza varias estructuras de datos que varan con el tiempo, similares a las empleadas en el algoritmo del banquero 7.5.3):

Disponible: Un vector de longitud m indica el nmero de recursos disponibles de cada tipo.

Sean Trabajo y Fin vectores con longitud m y n, respectivamente. Asgnese Trabajo := Disponible. Para = 1, 2, ..., n, si + O, entonces si no, := true. 2. Busque un ndice i tal que y a. b. Solicitud Trabajo. Si no existe tal i, ir al paso 4. 3. Trabajo := Trabajo + Asignacin; := true ir al paso 2.

226


7.6

Deteccin de bloqueos mutuos

227

4. Si = false, para alguna i, 1 i n , el sistema est en estado de bloqueo mutuo. Es ms, si = false, el proceso est en bloqueo mutuo.

satisfacer las solicitudes de los dems procesos; por tanto, existe un bloqueo que consiste en los procesos y

7.6.3 Uso del algoritmo de deteccindebemos invocar el algoritmo de deteccin? La respuesta depende de dos factores:1. 2.

Este algoritmo requiere del orden de m operaciones para detectar si el sistema est en bloqueo mutuo o no. El lector tal vez se pregunte por qu recuperamos los recursos del proceso (en Trabajo (en el paso 2b). el paso 3) tan pronto como determinamos que Solicitud i Sabemos que actualmente no est implicado en un bloqueo mutuo (ya que Trabajo). Por tanto, adoptamos una actitud optimista y suponemos que no necesitar ms recursos para llevar a cabo su tarea, y pronto devolver al sistema todos los recursos que tiene asignados. Si nuestro supuesto es incorrecto, podra ocurrir un bloqueo mutuo posteriormente. Ese bloqueo mutuo se detectar la prxima vez que se invoque el algoritmo de deteccin de bloqueos mutuos. Para ilustrar este algoritmo, consideremos un sistema con cinco procesos, a y tres tipos de recursos, A, B y C. El tipo de recursos A tiene 7 ejemplares, B tiene 2 tenemos el ejemplares y C tiene 6 ejemplares. Supongamos que, en el instante estado de asignacin de recursos siguiente:

es probable que ocurran bloqueos mutuos? cuntos procesos afectar un bloqueo mutuo si ocurre?

Solicitud ABC 0o0 202 ABC

Disvonible

ABC

ooo

200 303 211 002 100 002

Decimos que el sistema no est en estado de bloqueo mutuo. Efectivamente, si ejecutamos nuestro algoritmo, veremos que la secuencia tendr = true para toda como resultado que Supongamos ahora que el proceso solicita ejemplar adicional de un recurso tipo C. La matriz Solicitud se modifica como sigue:

Solicitud

Si los bloqueos mutuos son frecuentes, el algoritmo de deteccin deber invocarse muy seguido. Los recursos asignados a procesos bloqueados estarn ociosos hasta que se pueda romper el bloqueo mutuo. Adems, el nmero de procesos implicados en el ciclo de bloqueo mutuo podra crecer. Los bloqueos mutuos slo pueden aparecer cuando algn proceso hace una solicitud que no puede atenderse de inmediato. Es posible que dicha solicitud sea la que completa una cadena de procesos en espera. En un extremo, podramos invocar el algoritmo de deteccin de bloqueos mutuos cada vez que una solicitud de asignacin no se puede atender de inmediato. En este caso, no slo podremos identificar el conjunto de procesos que estn en bloqueo mutuo, sino tambin el proceso especfico que "caus" el bloqueo mutuo. (En realidad, cada uno de los procesos bloqueados es un eslabn en el ciclo del grafo de asignacin de recursos, as que todos ellos, en conjunto, causaron el bloqueo mutuo.) Si hay muchos tipos de recursos distintos, una solicitud podra causar muchos ciclos en el grafo de recursos, cada uno de ellos cerrado por la solicitud ms reciente y "causado" por el proceso que se puede identificar. Desde luego, la invocacin del algoritmo de deteccin de bloqueos mutuos en cada solicitud podra incurrir en un gasto extra de tiempo de cmputo considerable. Una alternativa menos costosa es simplemente invocar el algoritmo a intervalos menos frecuentes; por ejemplo, una vez cada hora, o siempre que el grado de utilizacin de la CPU cae por debajo del (Un bloqueo mutuo tarde o temprano reduce el rendimiento del sistema y hace que la utilizacin de la CPU disminuya.) Si el algoritmo de deteccin se invoca en momentos arbitrarios, podra haber muchos ciclos en el grafo de recursos. Generalmente no podremos saber cul de los muchos procesos bloqueados "caus" el bloqueo mutuo.

ABC 000 202 001 100 002

7.7

Recuperacin despus de un bloqueo mutuoCuando un algoritmo de deteccin determina que existe un bloqueo mutuo, se dispone de varias alternativas. Una posibilidad es informar al operador que ha

Decimos que el sistema est en bloqueo mutuo. Aunque podemos recuperar los recursos asignados al proceso el nmero de recursos disponibles no basta para

228


7.7 Recuperacin despus de un bloqueo mutuo

229

ocurrido un bloqueo mutuo y dejar que lo maneje manualmente. La otra es dejar que el sistema se recupere del bloqueo mutuo automticamente. Hay dos opciones para romper un bloqueo mutuo. Una solucin es simplemente abortar uno o ms procesos para romper la espera circular. La segunda opcin es expropiar recursos de uno o ms de los procesos bloqueados.

7.7.2 Expropiacin de recursosPara eliminar bloqueos mutuos utilizando expropiacin de recursos, expropiamos sucesivamente algunos recursos de los procesos y se los damos a otros procesos hasta romper el ciclo de bloqueo mutuo. Si se necesita expropiacin para manejar los bloqueos mutuos, es preciso considerar tres aspectos:

7.7.1 Terminacin de procesos

Para eliminar bloqueos mutuos abortando un proceso, utilizamos uno de dos mtodos. En ambos, el sistema recupera todos los recursos asociados a los procesos finalizados.

Abortar todos los procesos bloqueados: Es obvio que este mtodo romper el ciclo de bloqueo mutuo, pero el costo ser elevado, pues podra ser que estos procesos hayan trabajado durante largo tiempo, y los resultados de esas operaciones parciales tendrn que desecharse, y tal vez recalcularse despus. Abortar un proceso a la vez hasta eliminar el ciclo de bloqueo mutuo: Este mtodo incurre en un gasto extra considerable, ya que despus de abortar cada proceso se debe invocar un algoritmo de deteccin de bloqueos mutuos para determinar si todava hay procesos en bloqueo mutuo.

Cabe sealar que la terminacin forzada de un proceso podra no ser fcil. Si el proceso estaba actualizando un archivo, abortarlo a la mitad dejara el archivo en un estado incorrecto. As mismo, si el proceso estaba imprimiendo datos en la impresora, el sistema deber restablecer el estado de la impresora a un estado correcto antes de proceder con la impresin del siguiente trabajo. Si se emplea el mtodo de terminacin parcial, entonces, dado un conjunto de procesos en bloqueo mutuo, deberemos determinar cul (o cules) procesos se deben terminar para tratar de romper el bloqueo mutuo. Esta determinacin es una decisin de poltica, similar a los problemas de planificacin de la CPU. La cuestin es bsicamente econmica; deberemos abortar aquellos procesos cuya terminacin incurra en un costo ms bajo. Desafortunadamente, el trmino costo mnimo no es muy preciso. Muchos factores podran influir en la seleccin de los procesos, entre ellos:

l . Seleccin de la vctima: recursos de cules procesos se deben expropiar? Al igual que en la terminacin de procesos, debemos determinar el orden de expropiacin para minimizar el costo. Los factores de costo podran incluir parmetros tales como el nmero de recursos que un proceso bloqueado tiene asignados, y el tiempo que un proceso bloqueado ha consumido durante su ejecucin. 2. Retroceso:Si expropiamos un recurso de un proceso, debe hacerse con ese proceso? Es evidente que no podr continuar con su ejecucin normal, ya que le falta algn recurso que necesita. Debemos regresar el proceso a algn estado seguro, y reiniciarlo desde ese estado. Dado que, en general, es difcil determinar estado es seguro, la solucin ms sencilla es un retroceso total: se aborta el proceso y luego se reinicia. No obstante, es ms conveniente hacer retroceder el proceso slo hasta donde sea necesario para romper el bloqueo mutuo. Por otra parte, este mtodo obliga al sistema a mantener ms informacin acerca del estado de todos los procesos en ejecucin. 3. Inanicin: nos aseguramos de que no habr inanicin? Es decir, podemos garantizar que no siempre se expropiarn los recursos del mismo proceso? En un sistema en el que la seleccin de la vctima se basa primordialmente en factores de costo, podra suceder que siempre se escoja el mismo proceso como vctima. En consecuencia, dicho proceso nunca terminara su tarea designada, situacin de inanicin que es preciso resolver en cualquier sistema prctico. Queda claro que debemos asegurar que un proceso dado ser escogido como vctima un nmero finito (pequeo) de veces. La solucin ms comn es incluir el nmero de retrocesos en el factor de costo.

1. Qu prioridad tiene el proceso 2. Cunto tiempo ha trabajado el proceso, y cunto trabajar antes de llevar a cabo su tarea designada 3. Cuntos recursos ha usado el proceso, y de qu tipo (por ejemplo, si los recursos se pueden expropiar fcilmente) Cuntos recursos adicionales necesita el proceso para terminar su tarea. 5. Cuntos procesos habr que abortar 6. Si los procesos son interactivos o por lotes

7.8

Estrategia combinada para el manejo de bloqueos mutuosLos investigadores argumentan que ninguna de las estrategias bsicas para manejar bloqueos mutuos (prevencin, evitacin y deteccin) por s sola es apropiada para todo el espectro de problemas de asignacin de recursos que se presentan en los sistemas operativos. Una posibilidad es combinar los tres enfoques bsicos, y permitr el uso de la estrategia ptima para cada clase de recursos del sistema. El mtodo propuesto se basa en la idea de que los recursos pueden dividirse en clases que tienen un ordenamiento jerrquico. Se aplica una tcnica de ordenamiento de

230


Ejercicios

231

recursos 7.4.4) a las clases. Dentro de cada clase, se usa la tcnica ms adecuada para manejar bloqueos mutuos. Es fcil demostrar que un sistema que implementa esta estrategia no estar sujeto a bloqueos mutuos. Efectivamente, en un bloqueo mutuo no puede intervenir ms de una clase, ya que se emplea la tcnica de ordenamiento de recursos. Dentro de cada clase, se utiliza una de las estrategias bsicas. Por tanto, no puede haber bloqueos mutuos en el sistema. Para ilustrar esta tcnica, consideremos un sistema que consiste en las cuatro clases de recursos siguientes:

Permitir que el sistema entre en un estado de bloqueo mutuo y luego se recupere. Desentenderse del problema, y hacer como si nunca ocurrieran bloqueos mutuos en el sistema. Esta solucin es la que ha adoptado la mayor parte de los sistemas operativos, incluido UNIX.

Recursos internos: utilizados por el sistema, como un bloque de control de proceso Memoria central: Memoria utilizada por un trabajo de usuario Recursos de trabajos: Dispositivos asignables (como unidades de cinta) y archivos Espacio intercambiable: Espacio para cada trabajo de usuario en el almacenamiento auxiliar

Una solucin mixta para este sistema ordena las clases como se muestra, y utiliza las siguientes estrategias con cada clase:

Recursos internos: Se puede usar prevencin mediante ordenamiento de sos, ya que no es necesario escoger entre solicitudes pendientes en el momento de la ejecucin. Memoria central: Se puede usar prevencin mediante expropiacin, ya que los trabajos siempre pueden intercambiarse a disco, y la memoria central puede expropiarse. Recursos de trabajos: Se puede usar la evitacin, ya que la informacin requerida acerca de las necesidades de recursos se puede obtener de las tarjetas de control de trabajos. Espacio intercambiable: Se puede usar preasignacin, pues casi siempre se conocen las necesidades de almacenamiento mximas.

Puede ocurrir una situacin de bloqueo mutuo si y slo si se cumplen simultneamente cuatro condiciones necesarias en el sistema: mutua exclusin, retener y esperar, no expropiacin y espera circular. Para prevenir los bloqueos mutuos nos aseguramos de que al menos una de las condiciones necesarias nunca se cumplir. Otro mtodo para evitar los bloqueos mutuos que es menos drstico que los algoritmo~ prevencin consiste en tener informacin a priori acerca de la forma en de que cada proceso utilizar los recursos. El algoritmo del banquero necesita saber el nmero mximo de ejemplares de cada clase de recursos que cada proceso podra solicitar. Con esta informacin, podemos definir un algoritmo de evitacin de bloqueos mutuos. Si un sistema no emplea un protocolo para asegurar que nunca ocurrirn bloqueos mutuos, tendr que implementar un esquema de deteccin y recuperacin. Es preciso invocar un algoritmo de deteccin de bloqueos mutuos para determinar si ha ocurrido uno. Si se detecta un bloqueo mutuo, el sistema deber recuperarse, ya sea terminando algunos de los procesos bloqueados o expropiando los recursos de algunos de esos procesos. En un sistema que selecciona las vctimas que debern retroceder con base en factores de costo, cabe la posibilidad de inanicin. En tal caso, el proceso seleccionado nunca llevara a cabo su tarea designada. Por ltimo, algunos investigadores argumentan que ninguno de estos enfoques bsicos por s solo es apropiado para toda la gama de problemas de asignacin de recursos que enfrentan los sistemas operativos. Es posible combinar las estrategias bsicas y seleccionar individualmente la mejor para cada clase de recursos de un sistema.

Ejercicios

Este ejemplo muestra la forma en que las diversas estrategias bsicas pueden combinarse dentro del marco del ordenamiento de recursos, a fin de obtener una solucin efectiva al problema del bloqueo mutuo.

7.9

Resumen

Ocurre un estado de bloqueo mutuo cuando dos o ms procesos estn esperando indefinidamente un suceso que slo uno de los procesos que esperan puede causar. Hay tres mtodos principales para manejar los bloqueos mutuos:

Usar algn protocolo que garantice que el sistema nunca entrar en un estado de bloqueo mutuo.

7.1 Cite tres ejemplos de bloqueos mutuos no relacionados con un entorno de sistema de computacin. 7.2 posible tener un bloqueo mutuo en el que slo intervenga un proceso? Explique su respuesta. 7.3 Se ha planteado que un uso apropiado de spool eliminara los bloqueos mutuos. Sin duda, ello elimina de la contencin los lectores de tarjetas, graficadores, y dems. Incluso es posible manejar cintas con spool (lo que se conoce como por etapas), lo que dejara pendientes los recursos de tiempo de CPU, memoria y espacio en disco. posible tener un bloqueo mutuo en el que intervengan estos recursos? De ser as, podra ocurrir tal bloqueo mutuo? Si no, qu no? esquema para manejar bloqueos mutuos cree usted que sera el mejor para eliminar estos bloqueos mutuos (si son posibles), o qu condicin se viola (si no son posibles)?

232


Ejercicios

233

7.8 Considere un sistema que consiste en cuatro recursos del mismo tipo, compar-

7.9

7.10

Figura 7.8 Bloqueo mutuo de trfico para el ejercicio 7.4.

7.4 Considere el bloqueo mutuo de trfico que se muestra en la figura 7.8. 7.11

7.12

7.13

tidos por tres procesos, cada uno de los cuales necesita cuando ms recursos. Demuestre que el sistema est libre de bloqueos mutuos. Considere un sistema que consiste en m recursos del mismo tipo, compartidos por procesos. Los procesos slo pueden solicitar y liberar recursos uno por uno. Demuestre que el sistema est libre de bloqueos mutuos si se cumplen las dos condiciones siguientes: a. La necesidad mxima de cada proceso es de entre 1 y m recursos b. La suma de todas las necesidades mximas es menor que m + n Considere un sistema de computador que ejecuta 5000 trabajos al mes sin un esquema de prevencin o de evitacin de bloqueos mutuos. Ocurren bloqueos mutuos aproximadamente dos veces al mes, y el operador debe terminar y volver a ejecutar cerca de 10 trabajos cuando ocurre un bloqueo mutuo. Cada trabajo cuesta unos $2 dlares (en tiempo de UCP), y los trabajos que se abortan suelen estar a la mitad de su ejecucin en ese momento. Un programador de sistemas ha estimado que se podra instalar un algoritmo de evitacin de bloqueos mutuos (como el algoritmo del banquero) el sistema, y que ello incrementara el tiempo de ejecucin de cada trabajo aproximadamente en un 10% (en promedio). Puesto que la mquina actualmente est ociosa el 30% del tiempo, sera posible seguir ejecutando los 5000 trabajos al mes, aunque el tiempo de retorno aumentara en un 20% (en promedio). a. Cite argumentos a favor de instalar el algoritmo de evitacin de bloqueos mutuos. b. Cite argumentos en contra de instalar el algoritmo de evitacin de bloqueos mutuos. Podemos obtener el algoritmo del banquero para un solo tipo de recursos a partir del algoritmo general con slo reducir en uno las dimensiones de los diversos arreglos. Muestre, con un ejemplo, que el esquema del banquero para mltiples recursos no puede implementarse mediante la aplicacin individual del esquema para un solo tipo de recursos, a cada tipo de recursos. un sistema detectar que algunos de sus procesos sufren inanicin? Si responde afirmativamente, explique cmo podra hacerlo. Si responde negativamente, explique cmo el sistema podra enfrentar el problema de la inanicin. Considere la siguiente instantnea de un sistema:

Asignacin ABCD 0012 1000 1354 0632 0014

Mx ABCD 0012 1750 2356 0652 0656 ABCD 1520

a. Demuestre que las cuatro condiciones necesarias para el bloqueo mutuo se cumplen en este ejemplo. b. Plantee una regla sencilla que evite los bloqueos mutuos en tal sistema. 7.5 Suponga que un sistema est en un estado inseguro. Demuestre que los procesos pueden finalizar su ejecucin sin caer en un estado de bloqueo mutuo. 7.6 En un sistema de computacin real, ni los recursos disponibles ni las demandas de recursos que hacen los procesos son consistentes durante periodos largos (meses). Los recursos se descomponen o reemplazan, procesos nuevos llegan y se van, se traen nuevos recursos y se agregan al sistema, etc. Si los bloqueos mutuos se controlan con el algoritmo del banquero, de las siguientes modificaciones podran hacerse sin peligro (sin introducir la posibilidad de un bloqueo mutuo), y en qu circunstancias? a. Aumentar Disponible (adicin de nuevos recursos) b. Reducir Disponible (eliminacin permanente de recursos del sistema) c. Aumentar Mx para un proceso (el proceso necesita ms recursos que los permitidos, podra querer ms) d. Reducir Mx para un proceso (el proceso decide que no necesita tantos recursos) e. Aumentar el nmero de procesos f. Reducir el nmero de procesos 7.7 Demuestre que el algoritmo de seguridad que se present en la seccin 7.5.3 requiere del orden de m operaciones.

234


Notas bibliogrficas

235

Conteste las preguntas siguientes empleando el algoritmo del banquero: a. contiene la matriz Necesidad? b. sistema est en un estado seguro? c. Si el proceso solicita puede atender de inmediato la solicitud? 7.14 Considere la siguiente poltica de asignacin de recursos. Se permite solicitar y liberar recursos en cualquier momento. Si una solicitud de recursos no puede satisfacerse porque los recursos no estn disponibles, examinamos todos los procesos que estn bloqueados esperando recursos. Si esos procesos tienen los recursos deseados, se les quitan y se otorgan al proceso solicitante. El tor de recursos que un proceso bloqueado est esperando se incrementa de modo que incluya los recursos que se le arrebataron. Por ejemplo, consideremos un sistema con tres tipos de recursos y el vector Disponible que inicialmente tiene el valor Si el proceso solicita los obtiene. Si pide los obtiene. Entonces, si pide se bloquea (el recurso no est disponible). Si ahora solicita obtiene el que est disponible y uno de los que se haban asignado a (porque est bloqueado). El vector Asignacin de baja a y su vector Necesidad aumenta a a. ocurrir un bloqueo mutuo? Si as es, d un ejemplo; si no, condicin necesaria no puede ocurrir? haber bloqueo indefinido? b. 7.15 Suponga que ha codificado el algoritmo de seguridad para evitacin de bloqueos mutuos y ahora se le ha pedido implementar el algoritmo de deteccin de bloqueos mutuos. usted hacerlo sencillamente usando el cdigo del algoritmo de seguridad y redefiniendo = Esperando i + donde es un vector que especifica los recursos que el proceso i est esperando, y Asignacin i se defini en la seccin Explique su respuesta.

Coffman et al. escribieron el algoritmo de deteccin de bloqueos mutuos para mltiples ejemplares de un tipo de recursos que describimos en la seccin 7.6.2. Howard sugiri originalmente la estrategia combinada para manejar bloqueos mutuos que describimos en la seccin 7.8. Isloor y Marsland Newton y Zoble ofrecen reseas generales y bibliografas tiles.

Notas bibliogrficas

Dijkstra fue uno de los primeros y ms influyentes investigadores que trabajaron en el rea de los bloqueos mutuos. Holt fue el primero en formalizar el concepto de bloqueos mutuos en trminos de un modelo torico de similar al presentado en este captulo. Holt trat el problema de la inanicin. Hyman proporcion el ejemplo de bloqueo mutuo de la legislacin de Kansas. sugiri los diversos algoritmos de prevencin, y dise el esquema de ordenamiento de recursos para el sistema IBM Dijkstra desarroll el algoritmo del banquero para evitar bloqueos mutuos cuando slo hay un tipo de recursos, y Habermann lo extendi a mltiples tipos de recursos. Habermann Holt y Parnas y mann han escrito tratamientos generales acerca de la evitacin de bloqueos mutuos declarando reservas. Los ejercicios 7.8 y 7.9 se tomaron de Holt

Documents

BLOQUEOS MUTUOS- Silberschatz Galvin