Scribd Logo
Upload

Welcome to Scribd!

  • Sistemas Operativos - Silberschatz Galvin - Cap7 - Bloqueos Mutuos PDF

    Uploaded by

    cranckcracker123
    18 views13 pages

    Original Title

    Sistemas Operativos - Silberschatz Galvin - Cap7 - Bloqueos Mutuos.pdf

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    18 views13 pages

    Sistemas Operativos - Silberschatz Galvin - Cap7 - Bloqueos Mutuos PDF

    Uploaded by

    cranckcracker123

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 13
    Capitulo 7 BLOQUEOS MUTUOS En un entorno de multiprogramacién, varios procesos podrian competir por un nii- mero finito de recursos. Un proceso solicita recursos; si tos no estan disponibles, el proceso pasa a un estado de espera. Puede suceder que los procesos en espera nhunea vuelvan a cambiar de estado, porque los recursos que solicitaron estan en manos de otros procesos que también estén esperando. Esta situacién se llama blo- 4ueo mutuo (deadlock), y ya hablamos de ella brevemente en el capitulo 6, cuando tratamos los seméforos. Tal vez la mejor ilustracin de un bloqueo mutuo sea la que ofrece una ley apro- bbada por la legislatura de Kansas a principios de siglo. Esta ley rezaba, en parte: “Si dos trenes se aproximan uno al otro en un eruce, ambos harén alto total y ninguno arrancara de nuevo hasta que el otzo se haya ido, En este capitulo describiremos los métodos que un sistema operativo puede uti- lizar para resolver el problema de los bloqueos mutuos. Cabe sefialar que la mayor Parte de los sistemas operatives actuales no cuenta con mecanismos de prevencién de bloqueos mutuos. Es probable que tales funciones se incorporen en el futuro, a ‘medida que los problemas de bloqueo mutuo se vuelvan mas comunes, Varias ten- dencias causardn esta situacién, entre ellas el aumento en el mimero 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 sistema Un sistema consiste en un niimero 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 idénticos. El espacio de memo- 208 Capitulo7 Bloqueos mutuos ria, los ciclos de CPU, los archivos y los dispositivos de E/$ (como impresoras y tunidades de cinta) son ejemplos de tipos de recursos. Si un sistema tiene dos CPU, el tipo de recursos CPU tiene dos ejemplares. Asi mismo, el tipo de recursos impre- sora podria tener cinco ejemplares. Si un proceso solicita un ejemplar de un tipo de recursos, la asignacién de cual- 4quier ejemplar del tipo satisfaré la solicitud, Si no es asf, es porque los ejemplares rho son idénticos, y no se han definido correctamente las clases de recursos, Por ejemplo, un sistema podrfa tener dos impresoras, las cuales se pueden definir co- mo pertenecientes a la misma clase de recursos si a nadie le importa cusl impresora imprime cudles salidas. Sin embargo, si una impresora esta en el nove- no piso y la otra esté en el s6tano, la gente del noveno piso tal ver no las considere equivalentes, y podria ser necesario definir clases de recursos distintas para cada Ein proceso debe solicitar un recurso antes de usal,y debe Hberalo despues de usaf Un proceso puede soictar tantos recursos como neesite para eliza at ven designate Obviament, el numero de recursos soicados no puede exceder el mena de reeurwos con quel sistema cuenta, Dicho de oe odo, UP proce Corre puede slctar tes impresoras tel sistema slo tiene dos En lmode de fanconamionto normal, un proces slo puede wlizar un recur 1. Solicitud: Si la solicitud no puede atenderse de inmedtiato (por ejemplo, si otro proceso esté usando el recurso), el proceso solicitante deberd esperar hasta que pueda adquirir el recurso. Uso: El proceso puede operar con el recurso (por ejemplo, si el recurso es una im presora, el proceso puede imprimir en la impresora). 3, Liberacién: El proceso libera el recurso. La solicitud y liberacién del recurso son Hamadas al sistema, como se explicé en el capitulo 3. Ejemplos de tales lamadas son las de solicitar y liberar disposi tivo, abrir y cerrar archivo, y asignar y liberar memoria. La solicitud y liberacion de otros recursos puede efectuarse mediante las operaciones espera y sevial con se maforos. Por tanto, para cada uso, el sistema operative verifica que el proceso ‘usuario haya solicitado el recurso y se le haya asignado. Una tabla del sistema re- gistra si cada recurso esta libre asignado y, si un recurso esta asignado, a cual proceso se asigns. Si un proceso solicita un recurso que actualmente esté asi do a otro proceso, se le puede colocar en una cola de procesos que esperan ese ‘Un conjunto de procesos esta en un estado de bloqueo mutuo si cada uno de los procesos del conjunto esta esperando un suceso que sélo otro proceso del conjun- to puede causar. Los sucesos que mas nos interesan aqui son la adquisicién y liberacién de recursos. Los recursos pueden ser fisicos (como impresoras, unida- des de cinta, espacio de memoria y ciclos de CPU) © légicos (por ejemplo, archivos, semaforos y monitores). Ademas, hay otros tipos de sucesos que podrian oh vie DE ocUMEeACIIN Y BISLIOTRCA : BOS PONTEVIIES - URUGIAR, 72. Caracterizacién de bloqueos mutuos 209 dar pie a bloqueos mutuos (por ejemplo, el recurso IPC que mencionamos capitulo»). = “se 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 ha.adquirido una de estas unidades de cinta. $i ahora cada proceso solicita otra uni dad de cinta, los tres procesos estarén en un estado de bloqueo mutuo; cada uno estd esperando el suceso “se libera unidad de cinta”, que s6lo uno de tos otros pro- esos 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 también pueden estar implicados diferentes tipos de recur- S08. Por ejemplo, consideremos un sistema que tiene una impresora y una unidad de cinta. Supongamos que el proceso P; adquirié la unidad de cinta, y el proceso P,, Ja impresora. $i P;solicita la impresora y P;solicita la unidad de cinta, habré un bié- ‘queo mutuo. enel 7.2 = Caracterizacién de bloqueos mutuos Debe ser obvio que los bloqueos mutuos son indeseables. En un bloqueo mutuo, los pprocesos nunca terminan su ejecucién y los recursos del sistema quedan acapara- dos, lo que impide que otros trabajos puedan comenzar. Antes de estudiar los diferentes métodos para manejar el problema del bloqueo mutuo, describiremos los rasgos que caracterizan a los bloqueos mutuos. 7.2.1 Condiciones necesarias Puede surgir una situacién de bloqueo mutuo en un sistema si se cumaplen simults- neamente las cuatro condiciones siguientes: |. Mutua Exclusién: Al menos un recurso debe adquirrse de mod que no pueda compat sou pees ala ver pn st ee eat 5 Pr liberado el recurso. ' : " 7 2, Retener y esperar Debeevstir un proceso que haya aduirio al menos un = curso y estéesperando Para adquirr recursos adiclonales que ya han sido asignados a otros procesos, . 3. No expropiacto: Los ecussos no se pueden arebatay es deer a tibercion de que ha terminado su tarea. m , " " 4. Esper circular Debe exist un conjunto (Pp PP) de procesos en expert que Pesta esperano un curs que fe adguirido por P, Py est esperando un recurso que fue adguitida por Py Pests espeand un fecuso ue fata auido por Py, y Py est esperando un iecurso que fue adguride pos Py 210 Capitulo 7 Bloqueos mutuos Hacemos hincapié en que se deben cumplir las cuatro condiciones para que ocu- ran bloqueos mutuos. La condicién de espera circular implica la condicién de retener {y esperar, asf que las cuatro condiciones no son del todo independientes, No obstan- te, es util considerar cada condicién por separado, como veremos en la seccién 74. 7.2.2 Grafo de asignacién de recursos Los bloqueos mutuos se pueden describir con mayor precision en términos de un grafo ditigido llamado gra de asignacin de recursos del sistema, Este grafo consiste En un conjunto de vertices V y un conjunto de aristas E. El conjunto V se divide en ddos tipos de nods distintos: P = (Py, Pa,» P,, el conjunto de todos los procesos activos del sistema, y R= (Ry, Ry, «, Rel conjunto de todos los tipos de recursos ddl sistema ‘Uno arsta dirigida del proceso P; al tipo de recursos R;, denotada por P; > Rj, indi- ca que el proceso P; solcité un recurso del tipo R; y fsté espersndolo, Una’ arista {ivigida del tipo de recursos Bal proceso P; denotada por Rj ~> P indica que un ejem- plar de tipo de recursos R; se asigné al proceso P;- Una arista dirigida Pj — Ryes una bist de solicitud; una Rj 4 Pj es una arista de asignaci. u Graficamente, représentamos cada proceso P; con un cfrculo, y cada tipo de re- curso R; con un cuadrado. Puesto que el tipo de recursos Rj puede tener més de un ejemplat, representamos cada ejemplar como un punto dentro del cuadrado. Cabe Sefalar que una arista de solictud s6lo apunta al cuadrado Rj, mientras que una arista de asignacion también debe designar uno de los puntos que estén dentro del cuadrado. Cuando el proceso P; solicita un ejemplar del tipo de recursos Ri, se inserta una atis- ta de solicitud en el grato de asignacisn de recursos. En ef mémento en que dicha solicitud puede satistacerse, a arista de solicitud se transforma instantdueamente en tina arista de asignacidn. Cuando el proceso ya no necesita acceder al recurso, lo i= bbera y laarista de asignacién se bora Fl grafo de asignacion de recursos que se muestra en la figura 7.1 representa la situacién siguiente: # Los conjuntos P, Ry E © PPh, Py Ps) © R=IRy Re, Ry Ri © B= UP Ry, Pa “> Ry Ry > Py, Rp» Pap Ra Pr Ry > Pah © Ejemplares de recursos: © Un ejemplar del tipo de recursos Ry Dos ejemplares del tipo de recursos Ry © Un ejemplar del tipo de recursos Ry © Tres ejemplares del tipo de recursos Ry 7.2. Caractevizacién de bloqueos mutuos 211 Figura 7.1 Grafo de asignacién de recursos. ‘+ Estados de procesos: © EI proceso P tiene un ejemplar del tipo de recursos Ry y esté esperando un cjemplar del tipo de recursos Ry a © El proceso P, tiene un ejemplar de R, y Ry, y esté esperando un ejemplar de tipo de recursos R3. oe perandoun glmplar ce © El proceso P3 tiene un ejemplar del recurso Ry Dada la detinicidn de grafo de asignacion de recursos, se puede demostrar que siel grafo no contene cco, ringin proceso de sntema estar en blogueo MUU, Por otro lado, si el grafo contiene un ciclo, podeia existir un bloqueo mutuo. Si cada tipo de recursos tiene exactamente un ejemplar, un cielo implica que ha cecurrido un bloqueo mutuo. Si en el ciclo intervene s6lo un conjunto de tipos de recursos, cada tno de Ios cuales slo tiene un ejemplar, hay un bloqueo mutuo. Ca- 4a uno de los procesos que ntervienen ene eo est en Blogueo mutuo. En ete caso, un ciclo en el grafo es condicion necesaria y suticiente para la existencia de un bloqueo mutuo. a Si cada tipo de recursos tiene varios ejemplares, un ciclo no necesariamente im- plica que ha ocurrido un bloqueo mutuo. En este aso, un ciclo en el grafo es una condicidn necesaria pero no suficiente para la existencia de un blogueo mut. Para iustrar este concepto, regresemos al grafo cle asignaciéin de recursos que se muestra en la figura 7.1. Supongamos que el proceso P3 solicta un ejemplar del ti Bo de recursos, Dado que actualmente ne hay ning ejemplar de ese recurso isponible, se alade una arista de solicitud P ~» Ry al grafo (Fi este mo- ment, hay dos cls miimos ene stay” 21 8 E72) Eres Py Ry Pp > Ry Py Ry Py Py > Ry P3 > Ry > Py 212 Capitulo 7 Bloqueos mutuos % Figura 7.2 Grafo de asignacion de recursos eon bloqueo mutuo. Los procesos P;, P2 y Ps estan en bloqueo mutuo. El proceso P, ests esperando el recurso Ry, que fue adquirido por el proceso P, Este, a su vez, est esperando que el proceso P 0 el proceso P, libere el recurso Rp. Ademés, el proceso P, est espe- rando que el proceso P libere el recurso Ry, Consideremos ahora el grafo de asignacién de recursos de la figura 7.3. En este ejemplo, también tenemos un ciclo Py >R, > P39 RP} Sin embargo, no hay bloqueo mutuo. Observe que el proceso Py podria liberar su ejemplar de! tipo de recursos Rp, Entonees, ese recurso podria asignarse a P, lo que romperia el ciclo, TE sintosis, si un grafo de asignacién de recursos no tiene ciclos el sistema no es- 6 en estado de bloqueo mutuo. Por otra parte, si hay un ciclo, el sistema podria no estar en bloqueo mutuo, Esta observacidn es importante para manejar el proble- ‘ma del bloqueo mutuo. 7.3 = Métodos para manejar bloqueos mutuos Hay tos métodos principales para enfentarel problema de bloqueo mtu * Podemos usar un protocolo que asegure que el sistema nunca legard aun estado de bloqueo mutuo. + Podemos permitir que el sistema entre en bloqueo mutuo y Iuego se recupere. + Podemos desentendernos del problema y hacer como si nunca ocurrieran blo- {queos mutuos en el sistema, Esta solucidn es la que adopta la mayor parte de los, sistemas operatives, incluido UNIX. 73. Métodos para manejar bloqueos mutuos 213 —~ @ Figura 73 Grafo de asignacisn de recursos con un ciclo pero sin bloqueo mutwo, Profundizaremos tin poco mas en cada método. Luego, en las secciones 7.4 a 78, presentaremos algoritmos detalados, Para asegurar que nunca ocurran bloqueos mutuos, el sistema puede usar un es- quema de prevencién de bloqueos mutuos o bien uno de evitacion de bloqueos tutuos. La prevencién de blogieos mutuos es una serie de métodes que garartizan que al menos una de las condiciones necesarias (Sec. 721) no podra cumplitse Es tos métodos previenen los blogucos mutuos restringiendo la forma de hacer solicitudes de recursos. Analizaremos estos métodos en la seccibn 74 La evitacin de bloqueos mutues, en cambio, requiere proporcionar al sistema ope rativo informacién antcipada acerca de los recursos que un proceso va a soliltar y usar durante su existencla. Con esta informacién adicional, podemos decidis, para cada solicitud, si el proceso debe esperar o no. Cada solictud obliga al sistema considerar los recursos que estin disponibles, los que estén asignads a cada pror cosy las Futuras solicitudes y liberaciones de cada proceso, antes de deceit sila Solicitud en curso se puede satisfacer o debe diferitse. Estudiaremos estos esque: ‘mas en la seccign 75, Siu sistema no wtiliza un algoritmo de prevencién ce bloqueos mutuos, ni uno de evitacién de bloqueos mutuos, puede ocurrir una situacion de bloqueo mutt. En este enforno, el sistema podria contar con un algoritmo que examina el estado diel sistema para determinar si ha ocurrido un bloqueo mtu, y ot para tecupe rarse de tal situaci, en caso de presentarse. Examinaremos estas cuestiones en Tas secciones 76 y 77 Si un sistema no se asegura de que nunca ocurrirsn bloqueos mutuos, y tampo- co cuenta con un mecanismo para detectar los bloqueos mutuos y recuperarse de ellos, podriamos encontrarnos en una situacion en la que el sistema esta en un os tado de bloquco mutuo y no tiene manera de darse cuenta de lo que ha sucedid, En tal caso, el Bloqueo mutuo no detectado causard el deterioro del desempen del sistema, porque procesos que no pueden ejecutarse estin reteniendo recursos, y Porgue cada vez ms procesos, a medida que soliitan recursos, entran en un est 214 Capitulo 7 Bloqueos mutuos do de bloqueo mutuo, Tarde 0 temprano, el sistema dejaré de funcionar y tendré jue reiniciarse manualmente. se gunque este método no parece ser una estrategia viable para enfrentar el proble- ma del blogueo mutuo, es el que se usa en algunos sistemas operativos. En muchos sistemas, los blogqueos mutuos son muy poco frecuentes (digamos, uno al ao) por ello, es ms econdmico utilizar este método en lugar de los métodos mas costasos de prevencisn, evitacidn, deteccién y recuperacién de bloqueos mutuos que deben templearse constantemente. Ademés, hay circunstancias en las que el sistema est “congelado" sin que haya un bloquee mutuo. Como ejemplo de esta situacin, con- sideremos un proceso de tiempo real que se ejecuta con la prioridad mds alta (0 Ccalquier proceso que se ejecuta con un planificador no expropiativo) y nunca de- ‘vuelve el control al sistema operativo. 7.4 = Prevencién de bloqueos mutuos Como sefialamos en la seceién 7.2.1, para que ocurra un bloqueo mutuo se deben cumplir las cuatro condiciones necesarias. Si aseguramos que al menos una de es- tas 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. Mutua Exclusién Se debe cumplir la condicién de mutua exclusién para los recursos no compartibles. Por ejemplo, dos 0 més 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 archives sélo de lectura son un buen ejemplo de recurso compartible. Si varios procesos intentan abrir un archivo sélo de lectura al mismo tiempo, se les podré conceder acceso simulténeo al archivo. Un proceso nunca necesita esperar un recurso compartible. Sin embargo, generalmen- te no es posible prevenir los bloqueos mutuos negando la condicién de mutua cexclusidn; algunos recursos son intrinsecamente no compartibles. 7.4.2 Retener y esperar Para asegurar que la condiciGn dle retener y esperar nunca ocurra en el sistema, de- bemos garantizar que, siempre que un proceso solicite un recurso, no retenga ‘inguin otro recurso, Un protocolo que puede usarse obliga a cada proceso a solici- tar y recibir todos sus recursos antes de iniciar su ejecucidn. Podemos implementar esta medida exigiendo que las Ilamadas al sistema que solicitan recursos para un proceso precedan a todas las demés lamadas al sistema, Un protocolo alternative permite a un proceso solicitar recursos sélo cuando no tiene ninguno. Un proceso puede solicitar recursos y utilizarlos, pero antes de que 74. Prevencién de bloqueos mutuos 215 pueda solicitar recursos adicionales tendra que liberar todos Ios que actualmente fiene 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 de disco y luego imprime los resultados en una impresora. $i todos los recursos de- ben solicitarse en el momento en que un proceso inicia su ejecucién, el proceso deberd solicitar desde un principio la unidad de cinta, el archivo de disco y la im- presora,y rete la impresora durante toda su ejecucén, aunque solo a vaya a necesitar al final El segundo método permite al proceso solicitar inicialmente sélo la unidad de cinta y el archivo de disco. El proceso copia de la cinta al disco, y luego libera am- bos recursos. Luego, el proceso debe solicitar otra vez el archivo de disco, y la impresora. Después 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 utilizacién de los recursos podria ser baja, ya que muchos de los recursos podrian estar asigna- dos pero sin usarse durante periods largos, En el ejemplo dado, s6lo podriamos liberar la unidad de cinta y el archivo de disco, y luego solicitar otra vez el archivo de disco y Ia impresora, si podemos estar seguros de que nuestros datos permane- cen 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 inanicién. Un proceso que necesite varios recur sos muy solicitados podria tener que esperar indefinidamente porque al menos uno de los recursos que necesita siempre esté asignado a algtin otro proceso. 7.4.3 No expropiacién La tercera condicién necesaria es que no haya expropiacién de recursos que ya se hayan asignado. Para asegurar que esta condicién 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 fos recursos que actualmente tiene se liberaran implicitamente. Los recursos expro- piados se afadiran ala lista de recursos que el proceso esta esperando, y este ultimo. sélo se reiniciard cuando pueda recuperar sus antiguos recursos y los nuevos que esta solicitando, Como alternativa, si un proceso solicita algunos recursos, primero se compruc- ba que estén disponibles. $i asf es, los recursos se asignan; si no, se determina si estén asignados a algiin otro proceso que esti esperando recursos adicionales. $i se es el caso, se le quitan Ios recursos deseados al proceso que est esperando y leasignan al que los solicit6. Silos recursos no estén disponibles ni estan siendo re- tenidos por un proceso que espera, el proceso solicitante debera esperar. Mientras, el proceso espera, podria ser despojado de sus recursos, pero sélo si otro proceso los solicita. Un proceso solo puede reiniciarse si ya se le han asignado los recursos nuevos que solicité y si recupers cualesquier recursos que haya perdido mientras cesperaba, 216 Capitulo 7 Bloqueos mutuos Este protocolo se aplica a menudo a recursos cuyo estado se puede guardar facilmen- ley despues restaurarse, como registros de CPU y espacio de memoria; generalmente ro puede aplicarse a recursos tales como impresoras y unidades de cinta, 7.44 Espera circular Una forma de asegurar que la condicién de espera circular nunca se cumpla es im- poner un ordenamiento total de todos los tipos de recursos, y exigir que cada proceso solicite recursos en orden creciente de enumeracién. Sea R = {Ry Ry, Ry) el conjunto de tipes de recursos. Asignamos a cada tipo tun niimero entero tnico que nos permite comparar dos recursos y determinar si tune precede al otro en nuestro ordenamiento. En términos formales, definimos una funcién uno a uno F: R > N, donde N es el conjunto de niimeros naturales. Por ejemplo, si el conjunto de tipos de recursos R ineluye unidades de cinta, unidades de disco e impresoras, la funcién F podria definirse as: F(unidad de cinta) = 1, F(unidad de disco) = 5, FGimpresora) = 12. ‘Ahora podemos considerar el siguiente protocolo para prevenir bloqueos mu- tuos: un proceso sélo puede solicitar recursos en orden de enumeracién creciente. Es decir, un proceso puede solicitar inicialmente cualquier cantidad de ejemplares de un tipo de recursos, digamos Rj. Después, el proceso podrd solicitar ejemplares del tipo de recursos R; siy slo si F(R;) > F(R). Si se requieren varios ejemplares del mismo tipo de recursos, se deberé emitir wa sola solicitud que los incluya todos. Por ejemplo, empleando la funcidn que acabamos de definir, un proceso que desee usar la unidad de cinta y la impresora al mismo tiempo debera solicitar primero la uunidad de cinta y luego la impresora ‘Como alternativa, podiemos exigir que, siempre que un proceso solicite un ejem- plar del tipo de recursos R;, haya liberado cualesquier recursos R; que tenga, tales que FR = Fit). usdn estos dos protocolos, la condicién de espera circular no podra cumplir- se. Podemos demostrar esto suponiendo que existe una espera circular (demostracidn por contradiccién), Sea [Pp P},. P| el conjunto de procesos que in tervienen en la espera circular, donde P; est esperando un recurso Rj, el cual fue adquirido por el proceso P,. (Utilizamos aritmética de médulo con los subi de manera que P,, ests esperando un recurso R,, que fue adquirido por Py.) «es, puesto que el proceso P;. esta reteniendo el recurso R; y solicitando el recurso Rj, debe cumplirse que Fk) < F(R;.,,), para todo i. Sin embargo, esta condicion implica que F(Ry) < F(R;) < .. < F(Ry,) < F(Rp). Por transitividad, F(Rg) < F(Rg), lo. cual es imposible. Por tanto, no puede haber espera circular. abe sefalar que la funcién F debe definirse segiin el orden de uso normal de los recursos de un sistema, Por eemplo, dado quella unidad de cinta por lo regular se nece- sita antes que la impresora, seta razonable defini F(unidad de cinta) < Flimpresora) 75. Evitacién de bloqueos mutuos 217 7.5 = Evitacién de bloqueos mutuos Los algoritmos de prevencién de bloqueos mutuos, como vimos en la seccidn 74, se bbasan en restringir la forma de hacer solicitudes, Las restricciones aseguran que al menos una de las condiciones necesarias para el bloqueo mutuo no podra ocurris, y por ende que no podri haber bloqueos mutuos. Sin embargo, los posibles efectos s cundarios de la prevencidn de bloqueos mutuos empleando estos métodos son un bajo aprovechamiento de los recursos y una reduccidn del renclimiento del sistema, Un método alternative para evitar los bloqueos mutuos es pedir informacién adi ional acerca de la forma en que se solicitardn los recursos. Por ejemplo, en un sistema que tiene una unidad de cinta y una impresora, se nos podria decir que el proceso P solicitara primero la unidad de cinta, y luego la impresora, antes de libe- rar ambos recursos. El proceso Q, en cambio, solicitard primero la impresora luego la unidad de cinta, Con este conacimiento de la secuencia completa de soli tudes y liberaciones para cada proceso, podemos decidir, para cada solicitud, si el proceso debe esperar 0 no. Cada solicitud obliga al sistema a considerar los recur- ‘0s que estén disponibles en ese momento, los que ya se asignaton a cada proceso, ¥ las solicitudes y liberaciones futuras de cada proceso, para decidie si la solicitud ten curso se puede satistacer o debe esperar con el fin de evitar un posible bloqueo mutuo futuro. Los distintos algoritmos difieren en la cantidad y el tipo de la informacién reque- rida. El modelo mas til y sencillo obliga a cada proceso a declarag el raimnero mévimo dle recursos de cada tipo que pociria necesitat. Si tenemos informacién a priori acerca del niimero maximo de recursos dle cada tipo que cada proceso podria solicitar, po- dremos construir un algoritmo que asegure que el sistema nunca estaré en un estado de bloqueo mutuo. Este algoritmo define la estrategia de evitacgn de bloquens muluos Unalgoritmo de evitacién de bloqueos mutuos examina dinamicamente el estado de asignacién de recursos para asegurar que nunca pueda haber una condicion de es- pera circular. El estado de asignacién de recursos esté cefinido por el niimero de recursos disponibles y asignados, y las demandas maximas de los procesos. 7.5.1 Estado seguro Un estado es segiv si el sistema puede asignar recursos a cada proceso (hasta stu ma ximo) en algiin onden y aun asi evitar los bloqueos mutuos. En términos mas formales, un sistema estd en un estado seguro sélo si existe una secuencia segura. Una secuencia de procesos esperara hasta que cualquiera de los otros procesos hubiera terminado y liberado sus recursos, podriamos haber evitado la situacion de bloqueo mutuo. Dado el concepto de estado seguro, podemos definir algoritmos de evitacién que aseguren que el sistema nunca entraré en un bloqueo mutuo. La idea es simplemen- te asegurar que el sistema siempre permaneceré en un estado seguro. Inicialmente, el sistema esta en un estado seguro. Cada vez que un proceso solicita un recurso que esta disponible, el sistema debe decidir si es posible asignar el recurso de inme- diato 0 si el proceso debe esperar. La solicitud s6lo se atiende si la asignacién deja el sistema en un estado seguro. Cabe sefalar que, en este esquema, si un proceso solicita un recurso que esté dispo- nile, cabe la posibilidad de que tenga que esperar. Por ello la utilizaciGn de recursos podria ser menor de lo que serfa sin un algoritmo de evitacién de bloqueos mutuos. 7.5.2 Algoritmo de grafo de asignacién de recursos Si tenemos un sistema de asignacion de recursos con un solo ejemplar de cada tipo de recursos, podlemos usar una variante del grafo de asignacion de recursos que de- finimos en la seccién 7.2.2 para evitar los bloqueos mutuos. ‘Ademés de las arstas de solicitud y asignacién, introduclmos un nuevo tipo de arista, llamada arista de eseroa, Una arista de reserva P; ~» R; indica que el proceso >; podria solicitar el recurso Rj en algtn instante futuro, Esta arista se parece a una de solicitud en cuanto a su direccién, pero se representa con una linea discontinua Cuando el proceso P; solicita el recurso R; la arsta de reserva P; -> R; se convier: te en una de solicitud. Asf mismo, cuando P; libera un recurso Rj la arista de asignacidn Rj — P; se vuelve a convertir en una arista de reserva Pj > Rj, Cabe se- falar que los recursos deben reservarse « priori en el sistema; es deci, ates que el proceso P; inicie su ejecucién todas sus arstas de reserva deberan aparecer ya en el grafo de asignacidn de recursos. Podemos relaja esta condicién permitiendo la adi- cin de una arsta de reserva P; > Rj al grafo solo si todas las arstas asociadas al proceso P; son aristas de reserva. Supongamos que el proceso P solicit el recurso R). La solicitud sélo puede satis facerse sila conversion de la arista de solcitue PR en «ina arista de asignacion Rj Pjno da pie a un ciclo en ol grafo de asignacién e recursos. Observe que ve- riticamos la seguridad empleando un algoritmo de deteccién de cilos. En un grafo de este tipo, semejante algoritmo requiere del orden de n? operaciones, donde n es el nero de procesos del sistema, Si no existe ningsin ciclo, la asignaciGn del recurso dejard el sistema en un esta- do seguro, Si se encuentra un ciclo, la asignacién llevard el sistema a un estado 220 Capitulo 7 Bloqueos mutuos A Figura 75 Grafo de asignacisn de recursos para evitacién de bloqueos mutuos. inseguro, En tal caso, el proceso P; tendria que esperar para recibir los recursos que solicits, Para ilustrar este algoritmo, consideremos el grafo de asignacién de recursos de la figura 7.5. Supongamos que P, solicita Ry. Aunque Rz de momento esta libre, no podemos asignarselo a Rp porque tal accién erearfa un ciclo en el grafo (Fig. 7.6). Un ciclo indica que el sistema estd en un estado inseguro. Si P} solicita Ry, y P soli Ry, ocurrira un blogueo mutuo. 7.5.3 Algoritmo del banquero El grafo de asignacidn de recursos no puede aplicarse a un sistema de asignacién de re- ‘cursos con multiples ejemplares de cada tipo de recursos. E]algoritmo de evitacion de recursos que describiremos a continuacion puede aplicarse a tal sistema, pero es me- nos eficiente que el esquema de grafo de asignacion de recursos. Dicho algoritmo se ‘conoce como algoritmo del bauer, Se escogid este nombre porque el algoritmo podria tsarse en an sistema bancario para asegurar que el banco nunca asigne su efective dis- ponible de tal manera que ya no pueda satisfacer las necesidads de todos sus clientes. Cuando un proceso nuevo ingresa en el sistema, debe declarar el ntimero maxi- mo de ejemplares de cada tipo de recursos que podria necesitar. Este mimero no puede exceder el total de recursos del sistema, Cuando un usuario solicita un con- junto de recursos, el sistema debe determinar si la asignacién de esos recursos dejaria el sistema en un estado seguro. $i asf es, los recursos se asignan; sino, el pro- eso deberd 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 asignacién de recur- sos, Sea ir el ntimero de procesos del sistema, y m, el ntimero de tipos de recursos. Necesitamos las siguientes estructuras de datos: ‘+ Disponible: Un vector de longitud 1 indica el numero de recursos disponibles de cada tipo. $i Disponible|j] = k, hay k ejemplares disponibles del tipo de recur 808 Rj 75. Evitacién de bloqueos mutuos 221 % Figura 7.6 Estado inseguro en un grafo de asignacidn de recursos ‘+ Mx: Una matriz. X mm define la demanda maxima de cada proceso. Si Mit 4, el proceso P; puede solicitar cuando més k ejemplares del tipo de recursos R * Asignacign: Una matriz.n x m define el ntimero de recursos de cada tipo que se han asignado actualmente a cada proceso. Si Asignacigni] =k, el proceso P; tie- ne asignados actualmente k ejemplares del tipo de recursos R * Necesidad: Una matriz.1 X m indica los recursos que todavia lé hacen falta a cada proceso. Si Necessad|i,] = k, el proceso P; podria necesitar k ejemplares més del tipo de recursos Rj para llevar a cabo Su tarea, Observe que Necesidadlij] = Madi - Asignacigily) Las estructuras de datos anteriores varfan con el tiempo, tanto en tamaito como en valor. Para simplificar la presentacién del algoritmo del banquero, establezcamos una notacién. Sean X y ¥ vectores con longitud n. Decimos que X< Y si y s6lo si Xil = Yi) para toda i= 1, 2, .. n. Por ejemplo, si X = (1,732) y Y = (0.3.2.1), entonces Y EX. YeXsi¥ « ky VeX. Podemos tratar cada fila de las matrices Asignacign y Necesidad como vectores y referimos a ellas como Asignacién; y Necesidad;, respectivamente. El vector Asign= Cin expecitia los recursos que actualmente extn aignados al proceso Pel vector Necesidad; especitica los recursos adlicionales que el proceso P; todavia podria soli- citar para llevar a cabo su tarea, 7.53.1 Algoritmo de seguridad El algoritmo para averiguar si un sistema ests 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 va- lores iniciales Trabajo == Disponible y Fini] = fase parai= 1.2. me 2. Buscar una i tal que a. Fini] = false, y b. Necesidad; = Trabajo 222 Capitulo 7 Bloqueos mutuos Si no existe tal j, continuar con el paso 4 3, Trabajo := Trabajo + Asignacién Finfi] = true ir al paso 2 4. Si Fin[i] = true para toda i el sistema estd en un estado seguro. Este algoritmo podria requerir del orden dem x 1? operaciones para decidir si un estado es seguro 0 no. 7.5.3.2 Algoritmo de solicitud de recursos Sea Solicitud; el vector de solicitudes del proceso Pi; Si Solicitud] =k, el proceso P; quiere k ejemplares del tipo de recursos Rj, Cuando P; solicita recursos, se empren- Gen las aeciones siguientes: 1. Si Solicitud; < Necesidad;, ie al paso 2. En caso contrario, indicar una condicién de error, pues el proceso ha excedido su reserva maxima. 2. Si Solicitud, < Disponible, ir al paso 3. En caso contrario, P; deberd esperar, ya que los recursos no estén disponibles, 3, Hacer que el sistema simule haber asignado al proceso P; los recursos que solici- t6 modificando el estado como sigue’ Disponible := Disponible - Solicitud; Asignacion; == Asignacién; + Solicitud: Necesicad; != Necesidad; ~ Solicitud ‘ es fn se Tle- Si el estado de asignacién de recursos resultante es seguro, la transacci varé a cabo y se asignaran los recursos al proceso Pj; pero si el nuevo estado es inseguro, P, tendra que esperar Solicitud, y se restaurard el antiguo estado de asignacién de recursos. 7.53.3 Ejemplo ilustrativo Consideremos un sistema con cinco procesos, Py a Py y tres tipos de recursos A, By C. El tipo de recursos A tiene 10 ejemplares, & tiene 5 ejemplares y C tiene 7 ejempla- Asiguacién Mix Disponible Qc. ABC | AnG Py (010-753-332 P, 200 322 P, 302 902 P, 211 222 Py 002 433 7.6 DetecciOn de bloqueos mutuos 223, res, Supongamos que, en el instante Ty, se toms la siguiente instantnea del sistema El contenido de la matriz Necesidad se define como Mx ~ Asignacién y es Necesidad ABC Py 743 PL 122 Pp 600 P; 011 Py 431 Decimos que el sistema esta en un estado seguro, Efectivamente, la secuencia satisface los criterios de seguridad. Supongamos ahora que el proceso P solicita un ejemplar adicionat del tipo de recursos A y dos ejemplares del tipo de recursos C, de modo que Solicitud; = (10,2). Para decidir siesta solicitud se puede satisfacer de inmediato, primero verificamos que Solicitud, = Disponible (esto es, que (1,0,2) = (3,3,2)), lo cual es cierto. Ahora si mulamos que la solicitud se atendi6, y Hegamos al estado nuevo siguiente: Asignaciin Necesidad Disponible ABC ABC ABC Po 010 743 230 302 020 P, 302 600 P3241 oul Py 0026 | ai Debemos determinar si este nuevo estado del sistema es seguro, Para ello, eiecu- tamos nuestro algoritmo de seguridad y averiguamos que la secuencia > satisface nuestro requisito de seguridad, Por consiguiente, podemos aten. der de inmediato la solicitud del proceso P, No obstante, debe quedar claro que cuando el sistema esté en el estado anterior, 1no es posible satisfacer una solicitud (3,3,0) hecha por Py, ya que los recursos no es. ‘én disponibles. Tampoco puede atenderse una solicitud (0,2,0) hecha por Pa pesar de que los recursos estan disponibles, porque el estado resullante no es seguro. 7.6 = Deteccién de bloqueos mutuos Si un sistema no emplea un algoritmo de prevencién de bloqueos mutuos, ni uno de evitacién de bloqueos mutuos, podria presentarse una situacién de bloqueo mu- tuo. En un entorno asf, el sistema debe ofrecer: 224 Capitulo7 Bloqueos mutuos = Unalgoritmo que examine el estado del sistema y determine si ha ocurrido un bloqueo mutuo + Unalgoritmo para recuperarse del bloqueo mutuo) En la explicacién que sigue examinaremos mas de cerca estos dos requisitos y su importancia en sistemas que tienen tanto un solo ejemplar de cada tipo de recursos como varios ejemplazes de cada tipo de recursos, pero antes de hacerlo debemos se- falar que un esquema de deteccién y recuperacion requiere un gasto extra que inclaye no sélo los costos en tiempo de ejecucidn de mantener la informacién nece~ saria y ejecutar el algoritmo de deteccién, sino también las pérdidas potenciales inherentes a la recuperacién después de un bloqueo mutuo. 7.6.1 Un solo ejemplar de cada tipo de recursos Si todos los tipos de recursos tienen tinicamente un ejemplar, podemos definir un algoritmo de deteccién de bloqueos mutuos que utiliza una variante del grafo de asignacidn de recursos, llamada grafo de espera. Obtenemos este grafo a partir del sgrafo de asignacién de recursos eliminanda los nodos de tipo de recursos y unien- do las aristas apropiadas. En términos mas precisos, una arista de Pj a P; en un grafo de espera implica que el proceso Pesta esperando que el proceso P; libere un recurso que P; necesita. Hay tuna arista P; > Pjen un grafo de espera si y Sélo si el grafo de asignacién de recur- sos correspondiente contiene dos aristas Pj > Ry y Rg ~> P; para algtin recurso Ry, Por ejemplo, en la figura 7.7 presentamos un grafo de asignacidn de recursos y ¢ grafo de espera correspondiente. Igual que antes, existe un bloqueo mutuo en el sistema si y s6lo si el grafo de espe- +a contiene un ciclo, Para detectar los bloqueos mutuos, el sistema necesita mantener el grafo de espera e invocar periédicamente un algoritmo que busque ciclos en el grafo. Un algoritmo para detectar un ciclo en un grafo requiere del orden de 1? opera- ciones, donde 1 es el ntimero de vértices del grafo. 7.6.2 Varios ejemplares de un tipo de recursos Elesquema de grafos de espera no es aplicable a un sistema de asignacién de recur- sos en el que hay mltiples ejemplares de cada tipo de recursos. El algoritmo de deteccién de bloqueos mutuos que deseribimos a continuacién puede aplicarse esta clase de sistemas, y utiliza varias estructuras de datos que Varian con el tiem- po, similares a las empleadas en el algoritmo del banquero (Sec. 7.5.3): ‘Disponible: Un vector de longitud m indica el nimero de recursos disponibles de cada tipo, rsneznorsre PAGINA * pocumer i MONYEVIDE: 76 Deteccién de bloqueos mutuos 225 Q —-O—® % FI ey Figura 7,7 (a) Grafo de asignacién de recursos. (6) Grafo de espera correspondiente. ‘+ Asignaciéw: Una matriz.n x m define el mimero de recursos de cada tipo que ya ian asignado a cada proceso. pst * Solicitud: Una matriz n * m indica la solicitud actual de cada proceso. Si Solicitu- ali] = k, el proceso P; esta solictando k ejemplares adicionales del tipo de La relacion “menor que” (<) entre dos vectores se define igual que en la see- cin 7.53. Para simplifcar la notacidn, trataremos otra vez las files. de las matrices Asignacién y Solicitud como vectores, y nos referiremos a ellos como Asignacion;y Solicitud respectivamente, El algoritmo de deteccién que describ, fos agusimplement investiga todas fs poibles ecuencis de sgnacin para jos procesos que todavia no se llevan a cabo, Compare este algoritmo con el de! banquero (See. 7.5.3) ° ai - 1. Sean Trabajo y Fin vectores con longitud m y 1, respectivamente. Asignese Trba- 1 Diol Para) =1,2.0 m0 Again ot enone ol =a 0 Busque un indice ital que a. Fini] = fib, y b. Solicitud = Trabj. Si no existe tal ir al paso 4 3. Trabajo := Trabajo + Asignacion, Fini) == true iral paso2. 226 Capitulo7 Bloqueos mutuos 4. $i Fini = false, para alguna i, 1< <1, el sistema esta en estado de bloqueo mu- tuo. Es mds, si Fiali] » false, el proceso P; ests en bloqueo mutuo. Este algoritmo requiere del orden de m Xn? operaciones para detectar si el ss ma estd en bloqueo mutuo 0 no. lector tal vez se pregunte por qué recuperamos los recursos del proceso P (en el paso 3) tan pronto como determinamos que Solicitud; < Trabajo (en el paso 20). Sabemos que P; actualmente no esté implicado en un bloqueo mutuo (ya que Soli: cit, = Taiaj). Por tanto, adoptames una actitud optimista y suponemos que P; ‘no necesitard mas recursos para llevar a cabo su tarea, y pronto devolverd al siste- rma todos los recursos que tiene asignados. Si nuestro supuesto es incorrecto, podria ccurrir un bloqueo mutuo posteriormente. Ese bloqueo mutuo se detectard la pré- xima vez que se invoque el algoritmo de deteccién de bloqueos mutuos. Para ilustrar este algoritmo, consideremos un sistema con cinco procesos, Py a Py, {tes tipos de recursos, A, B y C. El tipo de recursos A tiene 7 ejemplares, B iene 2 ejemplares y C tiene 6 ejemplares. Supongamos que, en el instante Ty, tenemos el estado de asignacién de recursos siguiente: Asignaciin Solicitud — Disponible ABC ABC ABC Py 010 000 000 PL 200 © 202 P, 303 © 000 Py 211 100 P, 002 002 Decimos que el sistema no esté en estado de blogueo mutuo. Efectivamente, si eje cutamos nuestro algoritmo, veremos que la secuencia tendra como resultado que Finfi] = true para toda i Supongamos ahora que el proceso P; solicita un ejemplar adicional de un recur- s0 tipo C. La matri Solicitud se modifica como sigue: Solicitud ABC Py 000 ae 200 P, 001 P; 100 Py 002 Decimos que el sistema esta en bloqueo mutuo, Aunque podemos recuperar los re- ‘cursos asignados al proceso Py, el mimero de recursos disponibles no basta para 76 Deteccién de bloqueos mutuos 227 satisfacer las solicitudes de los demas procesos; por tanto, existe un bloqueo mutuo que consiste en los procesos P}, Pa, Py y Py, 7.6.3 Uso del algoritmo de deteccién {Cuando debemos invocar el algoritmo de deteccién? La respuesta cepende de dos Factores: 1. ;Con qué frecuencia es probable que ocurran bloqueos mutuos? 2. A cuintos procesos afectars un bloqueo mutuo si ocurre? Si los bloqueos mutuos son frecuentes, el algoritmo de deteccién deberd invocarse ‘muy seguido. Los recursos asignados a procesos blogueados estarén ociosos hasta que se pueda romper el bloqueo mutuo. Ademés, el asimero de procesos implica dos en el ciclo de blogueo mutuo podria crecer. Los bloqueos mutuos sélo pueden aparecer cuando algtin proceso hace tna solici- tud que no puede atenderse de inmediato. Es posible que dicha solicitud sea la que completa una cadena de procesos en espera. En un extreme, podriamos invocar ef a goritmo de deteccidn de bloqueos mutuos cada vez que una solicited de asignacién no se puede atender de inmediato. En este caso, no s6lo podremos identiicar el conjunto de procesos que estan en bloqueo mutuo, sino también el proceso especifico que "cat 56" elbloqueo mutuo. (En realidad, cada uno de los procesos bloqueadoses un eslabiin en el ciclo del grafo de asignacién de recursos, asi que todos ellos, en conjunto, causa- ron el bloqueo muluo) Si hay muchos tipos de recursos distintos, una solicitud podria causar muichos cclos en el grafo de recursos, cada uno de ellos cerrado por la solicitud mis reciente y “causaco por el proceso que se puede identifica. Desde luego, la invocacién del algoritmo de deteccién de bloqueos mutuos en ca- da solicitud podria incurrir en un gasto extra de tiempo de cémputo 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 utili zacién de la CPU cae por debajo del 40%. (Un bloqueo mutuo tarde o temprano reduce el rendimiento del sistema y hace que la utilizaciin de la CPU disminuya.) Si el algoritmo de deteccién se invoca en momentos arbtrarios, pode haber mu chos ciclos en el grafo de recursos. Generalmente no podremos saber cual de los muchos procesos bloqueacios “caus” el blogueo mutuo, 7.7 = Recuperacién después de un bloqueo mutuo Cuando un algoritmo de deteccién determina que existe un bloqueo mutuo, se dis- pone de varias alternativas. Una posibilidad es informar al operador que ha 28 Capitulo 7 Bloqueos mutuos ocurrido un bloqueo mutuo y dejar que 61 lo maneje manualmente. La otra es dejar aque el sistema se recupere del bloqueo mutuo autométicamente. Hay dos opciones para romper un bloqueo mutuo, Una solucidn es simplemente abortar uno 0 més procesos para romper la espera circular. La segunda opcién es expropiar recursos de uno o mas de los procesos bloqueados. 7.7.1 Terminacién de procesos Para eliminar bloqucos mutuos abortando un proceso, utilizamos uno de dos métodos, En ambos, el sistema recupera todos los recursos asociads a los procesos finalizados. + Abortar todos los procesos blogueados: Es obvio que este método rompers el ci- clo de bloqueo mutuo, pero el costo sera clevado, pues podria ser que estos procesos hayan trabajado durante largo tiempo, y los resultados de esas opera Giones parciales tendrén que desecharse, y tal ve7 recalcularse después. ‘+ Abortar un proceso a la vez hasta eliminar el ciclo de bloqueo mutuo: Este mé- todo incurre en un gasto extra considerable, ya que después de abortar cada proceso se debe invocar un algoritmo de deteccién de bloqueos mutuos para de- terminar si todavia hay procesos en bloqueo mutuo. Cabe sefialar que la terminacién forzada de un proceso podria no ser facil. Si el pro- ceso estaba actualizando un archivo, abortarlo a la mitad dejaria el archivo en un estado incorrecto. Asf mismo, si el proceso estaba imprimiendo datos en la impre- sora, el sistema debers restablecer el estado de la impresora a un estado correcto antes de proceder con la impresién del siguiente trabajo. Si se emplea el método de terminacidn parcial, entonces, dado un conjunto de procesos en bloqueo mutuo, deberemos determinar cull (0 cudles) procesos se de- ben terminar para tratar de romper el bloqueo mutuo. Bsta determinacién es una decisién de politica, similar a los problemas de planificaci6n de la CPU. La cues- tion es basicamente econémica; deberemos abortar aquellos procesos cuya terminacién incurra en un costo mas bajo, Desafortunadamente, el término costo minimo no es muy preciso. Muchos factores podrian influir en la seleccién de los procesos, entre ellos: 1, Que prioridad tiene el proceso 2. Cusnto tiempo ha trabajado el proceso, y cudnto trabajar antes de llevar a cabo su tarea designada 3, Cuantos recursos ha usado el proceso, y de qué tipo (por ejemplo, silos recursos se pueden expropiar fécilmente) ‘Culintos recursos adicionales necesita el proceso para terminar su tarea. ‘Cuntos procesos habré que abortar Silos procesos son interactivos 0 por lotes, 7.7 Recuperacién después de un bloqueo mutuo 229 7.7.2 Expropiacién de recursos Para eliminar bloqueos mutuos utilizando expropiacién de recursos, e 8, expropiamos. sucesivamente algunos recursos de los procesos y se los damos a otros procesos hasta romper el ciclo de blogueo mutuo. Si se necesita expropiacién para manejar los bloqueos mutuos, es preciso consi- derar tres aspectos: : a 1, Seleccién de ta victima:

    You might also like