- Definición de Abrazo
Mortal - Condiciones Necesarias para que
Ocurra un Abrazo Mortal - Preasignación de
recursos - Asignación con
restricciones - Detección y
recuperación - Prevención
- Algoritmos para evitar el
Deadlock - Formas de evitar un Abrazo
Mortal - Conclusión
- Bibliografía
Los abrazo mortales están muy desarrollados y es
un problema muy notables en el campo de los sistemas
operativos. El abrazo mortal es un conjunto de procesos en un
estado de
espera tal que ninguno de ellos tiene suficientes criterios para
continuar su ejecución.
El problema de los abrazos mortales no es único
al ambiente de
los sistemas
operativos. Generalizando nuestra interpretación de recursos y
procesos, podemos ver que un problema de abrazo mortal puede ser
parte de nuestro ambiente de vida diaria.
A continuación describiremos con mas profundidad
los siguientes aspectos:
- -
Condiciones para que ocurra un abrazo mortal - -
Prevención de Abrazos - -
Detección y recuperación de Abrazos - -
Formas de evitar un abrazo mortal.
Definición de
Abrazo Mortal (Deadlock)
Un conjunto de procesos está en un abrazo
mortal cuando todos los procesos en ese conjunto están
esperando un evento que sólo puede ser causado por otro
proceso en el
conjunto. Los eventos a los
cuales nos estamos refiriendo son concernientes con la
asignación y liberación de recursos principalmente.
Sin embargo, otro tipo de eventos pueden llevar a la existencia
de abrazos mortales.
En la teoría
de los sistemas
operativos, se puede definir el problema del Abrazo Mortal
como la situación de un conjunto de procesos en un estado
de espera tal que ninguno de ellos tiene suficientes criterios
para continuar su ejecución.
Circunstancias parecidas suceden a menudo en la vida
real, por ejemplo, en una carretera de dos direcciones, donde un
determinado punto de cruce con la vía férrea, se ha
construido un puente que por problemas
urbanísticos o de presupuesto
sólo deja pasar vehículos de un sentido. Dado este
punto crítico en la mencionada carretera, se presentan las
siguientes situaciones:
· Un vehículo llega al puente y no se
encuentra ningún otro en sentido contrario. En este caso,
cruza haciendo uso del puente y no ocurre nada
anormal.
· Si el paso por el puente es controlado por un
semáforo en cada lado
de manera que 100 metros antes de cada semáforo se
sitúen sendos detectores de presencia de vehículos
cuya finalidad sea poner en rojo el semáforo del sentido
contrario ante la presencia de un vehículo, podría
suceder que si llegan al mismo tiempo
vehículos en los dos sentidos se pongan los dos
semáforos en rojo impidiendo el paso de vehículos
en ambos sentidos. En este caso el camino queda bloqueado, lo que
representa un silogismo al Abrazo Mortal entre
procesos.
· Si no habiendo semáforos, el conductor
situado en uno de los extremos es losuficientemente educado que
deja pasar en primer lugar al del otro extremo y antes de
terminar de cruzar este último aparece por el mismo
extremo otro vehículo, y asísucesivamente mientras
aparezcan vehículos por el lado extremo. Esta
situación podemos emparejarla con la de
postergación indefinida que estudiaremos más
delante.
Visto el ejemplo anterior que nos introduce en los
conceptos básicos que vamos a tratar a continuación
referentes al Abrazo Mortal y a la postergación
indefinida, damos paso al estudio de recursos y del modelo de
sistema en los
que basaremos dichos conceptos.
Recursos
Se entiende como recurso un elemento que un programa o
proceso puede utilizar en la computadora
donde se está ejecutando. Se engloban bajo el concepto de
recurso, tanto los dispositivos hardware (por ejemplo, una
impresora),
como una cierta cantidad de información (por ejemplo, un registro de un
archivo).
No obstante, en una computadora
pueden existir muchos tipos de recursos, e incluso varios del
mismo tipo. Por ello definiremos un recurso como algo que puede
ser utilizado por un solo proceso en un instante dado. Para que
el proceso pueda utilizar un recurso, deberá realizar la
siguiente secuencia de operaciones:
· Solicitar el recurso. Si no estuviera
disponible el proceso, quedará bloqueado hasta que le
pueda ser asignado.
· Utilizar el recurso.
· Liberar el recurso
Modelo
En primer lugar vamos a definir lo que entendemos por
Abrazo Mortal. Se dice que un conjunto de procesos han alcanzado
un estado de Abrazo Mortal si cada uno de ellos espera que ocurra
algo que sólo puede ser producido por uno de los procesos
del propio conjunto (no necesariamente tiene que ser el mismo
suceso). Como todos los procesos están en espera, ninguno
de ello será el primero en producir el suceso deseado y
por tanto permanecerá esperando
indefinidamente.
Para formalizar todo lo expuesto hasta el momento, vamos
a fijar los principios en que
se basa todo sistema informático:
· Posee un número finito de
recursos.
· Existe un número finito de procesos que
compiten por los recursos.
· Los recursos se pueden dividir en tipos de tal
forma que cada uno de ellos esté compuesto por recursos
idénticos entre sí.
· Los procesos deben realizar las tres acciones
expuestas anteriormente sobre los recursos: solicitar, utilizar,
liberar.
· Un proceso puede pedir tantos recursos como
necesite para realizar su trabajo, ya
sean del mismo tipo o no, siempre que no excedan del total
existente en el sistema.
Condiciones Necesarias para que Ocurra un Abrazo
Mortal
Según Coffman (1971), existen cuatro condiciones
que deben cumplirse para que haya estancamiento. Una
situación de abrazo mortal puede surgir sí y solo
sí las siguientes cuatro condiciones ocurren
simultáneamente en un sistema:
1. Exclusión
Mutua. Los procesos reclaman control
exclusivo de los recursos que pide. Al menos un recurso es
mantenido en un modo no-compartible.
2. Retener y
Esperar. Los procesos que regularmente contienen recursos
otorgados antes pueden solicitar nuevos recursos. Debe existir
un proceso que retenga al menos un recurso y esté
esperando para adquirir recursos adicionales que están
siendo retenidos por otros procesos.
3. No existe el
derecho de desasignar. Los recursos no pueden ser
desasignados; esto es, un recurso sólo puede ser
liberado voluntariamente por el proceso que lo retiene,
después de que el proceso ha terminado su
tarea.
4. Espera
Circular. Debe haber una cadena de dos o más
procesos, cada uno de los cuales esté esperando un
recurso contenido en el siguiente miembro de la cadena. Debe
existir un conjunto {p0, p1, …,pn} de procesos en espera tal
que p0 esté esperando por un recurso que está
siendo retenido por p1, p1 está esperando por un recurso
que está siendo retenido por p2, …, pn-1 está
esperando por un recurso que está siendo retenido por pn
y pn está esperando por un recurso que está
siendo retenido por p0.
Las cuatro condiciones deben de cumplirse para que pueda
ocurrir un abrazo mortal. La condición de espera circular
implica la condición de retener y esperar, de tal manera
que las cuatro condiciones no son totalmente independientes. Sin
embargo, puede ser útil el considerar cada
condición por separado.
Una forma de modelar estas condiciones es usando un
grafo de recursos: los círculos representan
procesos, los cuadrados recursos. Una arista desde un recurso a
un proceso indica que el recurso ha sido asignado al proceso. Una
arista desde un proceso a un recurso indica que el proceso ha
solicitado el recurso, y está bloqueado
esperándolo. Entonces, si hacemos el grafo con todos lo
procesos y todos los recursos del sistema encontramos un ciclo,
los procesos en el ciclo están bajo bloqueo
mutuo.
Cuando un proceso
comienza determina los recursos que va a usar
Cuando todos
estén disponibles, comienza
Utilizado en el sistema
OS/360
Inconvenientes:
Es necesario conocer a priori los
recursos que se van a emplear
Puede que algún recurso
solicitado no se emplee
Se obtiene una baja
utilización de los mismos
El usuario está
obligado a establecer a priori qué recursos va a
utilizar
Al contrario que en el
caso anterior, el proceso comienza su ejecución y se le
van asignando recursos dinámicamente
Antes de asignar los
recursos se comprueba que el sistema permanece en un estado
seguro
¿Qué es
un estado seguro?
Cuando se utiliza esta técnica, el sistema no
hace nada salvo monitorear las requisiciones y devoluciones de
recursos. Cada vez que se solicita o se devuelve un recurso, la
gráfica de recursos se actualiza y se hace una
verificación para observar si existe algún ciclo.
Si existe uno, se elimina uno de los procesos contenidos en el
ciclo. Si esto no deshace el estancamiento, se elimina otro
proceso y así sucesivamente hasta que se rompa el
ciclo.
La detección y recuperación es la estrategia que a
menudo se usa en las macrocomputadoras, sobre todo los sistemas
por lotes en los que terminar y luego reiniciar un proceso suele
ser aceptable.
Si un sistema no emplea una prevención de
los abrazos mortales puede ocurrir un abrazo.
Entonces el sistema debe proporcionar:
– un algoritmo para
examinar cada estado del sistema
– un algoritmo para recuperarse de
los abrazos
Un algoritmo de detección y recuperación necesita
mantener cierta información además que existen
ciertas perdidas cuando nos recuperamos de un abrazo (tiempo que
los procesos no se ejecutan, etc.)
Como algoritmo de detección se puede emplear una
variante del algoritmo de seguridad visto
anteriormente. Si al terminar tenemos procesos con Terminado[i]
con valor FALSE,
estos procesos se encontrarán en abrazo mortal.
Problema: ¿Cuándo debemos invocar al algoritmo de
detección?
Depende de:
-
¿Cada cuánto tiempo se produce el abrazo
mortal?
si es frecuentemente el algoritmo de detección se invoca
con frecuencia los procesos durante el abrazo están
ociosos el número de procesos implicados en el abrazo
puede aumentar -
¿Cuántos procesos se ven implicados en
ello?
Podemos invocar al algoritmo:
-
Cada vez que se pide un nuevo recurso (mucho coste) -
Cada vez que se pide un recurso y no se concede -
Cada cierto intervalo de tiempo (X minutos) -
Cuando la carga del sistema cae por debajo de cierto
%
Los libros de
texto te
dirán que si siempre bloqueas en el mismo orden, nunca
obtendrás esta clase de
deadlock. La práctica te dirá que este tipo de
aproximación no escala bien:
cuando creo un nuevo bloqueo, no entiendo suficientemente el
núcleo para imaginarme dónde está él
en la jerarquía de los 5000 bloqueos.
Los mejores bloqueos están encapsulados; nunca
estarán expuestos en las cabeceras, y nunca se
mantendrán a través de llamadas a funciones no
triviales fuera del mismo archivo. Puedes leer a través de
este código
y ver que nunca hará deadlock, porque nunca intenta tener
otro bloqueo mientras tiene el uso. La gente usando tu
código no necesita saber nunca que estás usando un
bloqueo.
Un problema clásico aquí es cuando
suministras retrollamadas o trampas: si las llamas con el bloqueo
mantenido, arriesgas un deadlock simple, o un abrazo mortal
(¿quién sabe lo que hará la llamada?).
Recuerda, los otros programadores andan detrás de ti, por
lo tanto no hagas esto
Se ha llegado a la conclusión de que si falta
una de las cuatro condiciones necesarias, es imposible que
ocurra un bloqueo. Havender (HV68) sugirió las siguientes
estrategias para
evitar varias de estas condiciones:
1. Cada proceso
deberá pedir todos sus recursos requeridos de una sola
vez y no podrá proceder hasta que le hayan sido
asignados.
2. Si a un proceso que
mantiene ciertos recursos se le niega una nueva
petición, este proceso deberá liberar sus
recursos originales y, en caso necesario, pedirlos de nuevo
junto con los recursos adicionales.
3. Se impondrá la
ordenación lineal de los tipos de recursos en todos los
procesos, es decir, si a un proceso le han sido asignados
recursos de un tipo dado, en lo sucesivo sólo
podrá pedir aquellos recursos de los tipos que siguen en
el ordenamiento.
Exclusión mutua
Si nunca se asignara
un recurso exclusivamente a un solo proceso, nunca
tendríamos estancamiento. No obstante, que al permitir que
dos procesos se ejecuten se llegaría al caos. Por lo tanto
es una condición que no queremos romper.
1.- Retener y esperar: La primera estrategia
requiere que todos los recursos que va a necesitar un proceso
sean pedidos de una sola vez. El sistema deberá asignarlos
según el principio de "todo o nada". Con ésto, se
niega la condición de "espera por" y el bloqueo, no puede
producirse.
Esta estrategia puede llevar a un serio desperdicio
de recursos, así como a provocar
postergación indefinida. ya que quizá no todos
los recursos requeridos estén disponibles al mismo
tiempo.
Un enfoque de uso frecuente entre los implementadores de
sistemas para obtener una mejor utilización de recursos en
estas circunstancias, es dividir un programa en varios
pasos que se ejecuten con una relativa independencia
uno del otro. Entonces, la asignación de recursos puede
ser controlada por pasos, en lugar de establecer un control del
proceso total. Esto puede reducir el desperdicio, pero implica
gran sobrecarga en el diseño
de sistemas de aplicaciones, así como en su
ejecución.
Para ejemplificar la diferencia entre estos dos
enfoques, considere un proceso que copia un archivo de una unidad
de cinta(1) a una unidad de disco, ordena el archivo en disco,
después imprime los resultados a una impresora en
línea y finalmente copia el archivo de disco a la unidad
de cinta(2). Si todos los recursos deben ser solicitados al
inicio del proceso, entonces el proceso debe iniciar solicitando
la unidad de cinta(1), la unidad de disco, la impresora en
línea y la unidad de cinta(2). Este proceso
mantendrá las unidades de cinta (1) y (2) durante la
ejecución completa aunque solo las utilice al principio y
al final de su ejecución respectivamente.
El segundo método
permite al proceso el solicitar inicialmente solo la unidad de
cinta(1) y la unidad de disco. Así puede copiar el archivo
de la unidad de cinta (1) a la unidad de disco y ordenarlo,
posteriormente debe liberar la unidad de cinta(1) y la unidad de
disco. El proceso debe de volver a solicitar la unidad de disco y
la impresora en línea para hacer la impresión.
Después de imprimir debe de liberar la unidad de disco y
la impresora. Ahora debe de volver a solicitar la unidad de disco
y la unidad de cinta(2) para copiar el archivo a cinta, debe
liberar ambos recursos y terminar.
2.- No existe el derecho de desasignar: La
tercera condición necesaria es que no debe de existir el
derecho de desasignar recursos que han sido previamente
asignados. Con el fin de asegurar que esta condición no se
cumpla, se puede usar la siguiente estrategia. Si un proceso que
está reteniendo algunos recursos solicita otro recurso que
no puede ser asignado inmediatamente (esto es, que el proceso
tenga que esperar), entonces todos los recursos que tiene este
proceso en espera son desasginados. Esto es, los recursos son
liberados implícitamente. Los recursos liberados son
agregados a la lista de los recursos por los cuales está
esperando el proceso. El proceso solo puede volver a ser
reinicializado cuando haya obtenido otra vez todos los recursos
que tenía asignados así como el nuevo recurso que
estaba solicitando.
Alternativamente si un proceso solicita algunas
recursos, primero verificamos si estos están disponibles.
Si es así, entonces se le asignan. De otro modo, se
verifica si están asignados a alguno de los procesos que
están en espera de recursos adicionales. Si es así,
los recursos deseados son desasginados del proceso en espera y
asignados al proceso solicitante. De otra manera (no
están disponibles, ni asignados a procesos en espera)
el proceso que hace la solicitud debe esperar. Pero, mientras
está esperando, algunos de sus recursos pueden ser
desasignados solamente si estos son solicitados. Un proceso puede
ser reinicializado cuando se le asigna el recurso que
había solicitado y recupera cualquier recurso que haya
sido desasignado mientras esperaba.
Esta estrategia es utilizada usualmente sobre recursos
cuyo estado puede ser fácilmente salvado y restablecido
posteriormente, ejemplo de ellos son los registros del
CPU y el
espacio en la memoria.
Este no puede ser aplicado a recursos tales como impresoras.
3.- Espera circular: Con el fin de asegurarse de
que la condición de espera circular nunca se presente, se
puede imponer un ordenamiento total sobre todos los tipos de
recursos. Esto es, asignamos a cada tipo de recurso un
número entero único, el cual permita comparar dos
recursos y determinar cuando uno precede al otro en el
ordenamiento.
-
Los recursos deben ser pedidos en orden ascendente por
número de recurso. Los números de recurso son
asignados por la instalación y "hay que vivir con ellos"
durante largos periodos. -
Cuando se asignan los números de recurso deben reflejar
el ordenamiento normal en el cual la mayoría de los
trabajos van a utilizar esos recursos. Para los trabajos que se
acoplen a este ordenamiento puede esperarse una
operación eficiente. Pero para los que requieran de los
recursos en un orden diferente al supuesto en la
instalación, los recursos deberán ser adquiridos
y mantenidos mucho antes de su
utilización. -
El ordenamiento lineal elimina de forma efectiva la posibilidad
de espera circular, no obstante, crea un efecto contaminante
sobre la capacidad del usuario para escribir códigos de
aplicaciones de una forma fácil y libre.
Más formalmente, sea R={r1,r2,…,rn} el conjunto
de tipos de recursos. Puede definirse una función
uno a uno F:R->N, donde N es el conjunto de números
naturales. Por ejemplo, si el conjunto R de tipos de recursos
incluye unidades de disco (UDD), unidades de cinta (UDC),
lectoras ópticos (LO) e impresoras (I), entonces la
función F puede ser definida como sigue:
F(LO) =1
F(UDD) = 5
F(UDC) = 7
F(I) = 12
Cada proceso puede solicitar recursos sólamente
en un orden creciente de numeración. Esto es un proceso
puede solicitar inicialmente cualquier número de
instancias de un tipo de recurso, digamos ri. Después de
esto, el proceso puede solicitar instancias de recursos del tipo
rj si y solo si F(rj) > F(ri). Si varias instancias del mismo
tipo de recurso son necesitadas, debe hacerse una sola
petición para todas las instancias. Por ejemplo, usando la
función definida anteriormente, un proceso que quiere usar
el lector óptico (LO) y la impresora (I) debe solicitar
primero el (LO) y después la (I).
Debe notarse que la función F debe definirse de
acuerdo al ordenamiento de uso normal de los recursos en el
sistema. Por ejemplo, usualmente se utiliza primero una (UDD)
antes que la (I), por lo cual es razonable definir F(UDD) <
F(i).
El Algoritmo del Banquero. (The Banker's
Algorithm – Dijkstra (1965) Habermann (1969)) se basa en
determinar si los recursos que están libres pueden ser
adjudicados a procesos sin abandonar el estado
"seguro".
Supondremos N procesos y M clases de recursos y ciertas
estructuras de
datos
– Disponible : Vector de longitud M.
Disponible(j) = k, indica que existen k instancias
disponibles
del recurso r(j).
– MAX : Matriz de NxM.
Define la máxima demanda de
cada proceso. MAX(i,j) = k, dice
que p(i) requiere a lo sumo k instancias del recurso
r(j).
– Asignación : Matriz de NxM. Define el
número de recursos de cada tipo actualmente
tomados
por cada proceso. Asignación(i,j,) = k, dice que
el proceso p(i) tiene k instancias del recurso r(j).
– Necesidad : Matriz de NxM. Define el resto de
necesidad de recursos de cada proceso. Necesidad(
i,j) = k significa que el proceso p(i) necesita k
más del recurso r(j).
– Requerimiento : Es el vector de requerimientos
de p(i). Requerimiento (i)(j) = k, indica que p(i)
requiere k instancias del recurso r(j).
De lo cual se desprende que:
Necesidad(i,j) = MAX(i,j) –
Asignación(i,j)
Para simplificar utilizaremos la notación
siguiente:
Si X e Y son dos vectores:
X ≤ Y sii X(i) ≤ Y(i) para todo i y
X < Y sii X ≤ Y , y X ≠ Y.
Además trataremos aparte las matrices por
sus filas, por ejemplo, Asignación(i) define todos los
recursos
asignados por el proceso p(i).
Requerimiento(i) es el vector de requerimientos de
p(i).
Requerimiento(i)(j) = k indica que p(i) requiere k
instancias del recurso r(j).
ALGORITMO
Cuando se requiere un recurso se toman estas
acciones:
1. Si Requerimiento(i) ≤ Necesidad(i) seguir, sino
ERROR (se pide más que lo declarado en MAX(i)).
2. Si Requerimiento(i) ≤ Disponible seguir, si no
debe esperar, pues el recurso no está
disponible
3. Luego el sistema pretende adjudicar los recursos a
p(i), modificando los estados de la siguiente forma:
Disponible = Disponible – Requerimiento(i)
Asignación(i) = Asignación(i) +
Requerimiento(i)
Necesidad(i) = Necesidad(i) –
Requerimiento(i)
Si esta nueva situación mantiene al sistema en
estado "seguro", los recursos son adjudicados. Si el
nuevo
estado es "inseguro", p(i) debe esperar y,
además, se restaura el anterior estado de
asignación total de recursos.
Formas de Evitar un Abrazo Mortal
- -
Tener recursos compartidos - -
Poder
quitarle un recurso a un flujo - -
Poder conseguir todos los recursos que necesita en forma
atómica. - -
Ordenar las peticiones de recursos (tener que conseguirlos en
el mismo orden.
Para evitar DEADLOCKS, en los casos en que se deba
coexistir con las 4 condiciones necesarias, de debe conocer de
qué manera los procesos requerirán sus
recursos.
El modelo más sencillo es conocer de antemano la
cantidad máxima de cada tipo de recurso a necesitar.
Conocido esto es posible construir un algoritmo que permita que
nunca se entre en "estado de deadlock". Consisteen examinar
periódicamente el número de recursos disponibles y
asignados para evitar una "espera circular".
Un estado "seguro" (SAFE) es cuando se pueden
asignar recursos a cada proceso en algún orden y evitarel
deadlock.
Formalmente: Un sistema está en estado
"seguro" si existe una "secuencia segura de
procesos". Unasecuencia <p(1),p(2), …,p(n)> es segura
si por cada p(i) los recursos que necesitará pueden ser
satisfechos por los recursos disponibles más todos los
recursos retenidos por todos los p(j) tal que j < i. En este
caso p(i) puede esperar que todos los p(j) terminen, obtener
todos sus recursos y luego que los libera, el p(i+1) a su vez,
puedeobtener todos los recursos necesarios. Si esta secuencia no
existe el sistema está en estado inseguro
"UNSAFE".
Veamos un ejemplo:
Los procesos necesitarían cintas, existiendo un
máximo de 12 cintas disponibles.
P(0) —-> 10 P(1) —-> 4 P(2) —->
9
En un instante T(0) dado tienen asignado:
T(0) P(0) <—- 5 P(1) <—- 2 P(2) <—- 2 3
Libres
Existe una secuencia segura
<P(1),P(0),P(2)>.
Necesita Tiene
P(1) 4 2
P(0) 10 5
P(2) 9 2
P(1) toma 2 más. Cuando termina libera 4,
más la instancia que quedaba libre son 5, luego
P(0) toma 5. Cuando termina libera las 10 retenidas y
luego
P(2) toma 7 y luego termina.
Luego estamos en un estado seguro, con lo cual no
podemos pasar a un estado de "deadlock" si se asignan
los recursos en el orden dado por la secuencia
dada.
De un estado "seguro" podemos pasar a uno "inseguro"
(UNSAFE). Supongamos que en el instante T(1),
se da un recurso más a P(2) :
T1) P(0) <—- 5 P(1) <—- 2 P(2) <—- 3 2
Libres
Solo P(1) puede satisfacer sus requerimientos,
aquí no existe una secuencia segura, pues ni P(0), ni P(2)
pueden obtener la totalidad de recursos que requieren, entonces
podemos desembocar en un estado de "deadlock".
Si se hubiera respetado la secuencia "segura", esto no
se habría producido.
Luego se pueden definir algoritmos que
aseguren no entrar en un estado "inseguro", evitando en
conclusiónel estado de "deadlock".
Esto está indicando que cuando un recurso es
pedido, aún estando disponible, es necesario verificar si
no desembocará en un estado "inseguro".
El abrazo mortal es un conjunto de procesos en un estado
de espera tal que ninguno de ellos tiene suficientes criterios
para continuar su ejecución. Cuando cada proceso del
conjunto esta esperando por un evento que solo puede ser causado
por otro proceso que esta dentro de este conjunto.
El objetivo de un
abrazo mortal, ofrece una herramienta que nos permite modelar el
problema del abrazo mortal y ofrecer las soluciones del
mismo.
Entre las condiciones para que se produzca un abrazo
mortal tenemos, exclusión mutua, retener y esperar, no
existe el derecho de designar y espera circular. Estas cuatro
condiciones deben de cumplirse para que pueda ocurrir un abrazo
mortal.
La detección y recuperación es el sistema
que se utiliza para monitorear las requisiciones y devoluciones
de recursos, es la estrategia que a menudo se usa en las
macrocomputadoras sobre todos los sistemas por lotes en los que
terminan y luego se reinicia un proceso que suele ser
aceptable.
La prevención son problemáticos, pero no
son tan malos como la corrupción
de datos. El
código que obtiene un bloqueo de lectura, busca
una lista, falla al encontrar lo que quiere, tira el bloqueo de
lectura, obtiene un bloqueo de escritura e
inserta el objeto tiene una condición de
carrera.
La mejor forma de evitar los abrazos mortales es
ignóralos por completo. Y posteriormente resórbelos
en un determinado momento.
www.itq.edu.mx/vidatec/maestros/sis/mnogues/unidad2.htm
– 135k
es.tldp.org/Manuales-LuCAS/linux-bloqueo/
multiple-html/techniques-deadlocks.html – 8k.
http://personals.ac.upc.edu/juli/ISO-Comunicacion.pdf
html.rincondelvago.com/sistemas-operativos_37.html –
218k
atc1.aut.uah.es/~arqui/trps/abrazo_mortal.ppt
www.dc.uba.ar/people/materias/so/datos/cap17.pdf
–
Dolonnis Cachutt