Está en la página 1de 16

Trabajo de Sistemas Operativos

Tema: Interbloqueos
Alumnos:
• Marcos Acosta
• Juan Manuel Paredes
• Rodrigo Samaniego
• Gabriel Delvalle
• Florencia Rios
Profesor: Nicolas Rodríguez

Curso: 4to
Año: 2021

1
Índice
Introducción …………………………………………………………………………………………… 3
Introduccion al Interbloqueo …………………………………………………………………. 4
Detección y Recuperación de un interbloqueo………………………………………………7
Cómo prevenir interbloqueos………………………………………………………………….11
Bloqueo de dos fases ……………………………………………………… 13
Interbloqueo ………………………………………………………………. 13
Bloqueo Activo …………………………………………………………….. 14
Inanicion …………………………………………………………………… 14
Conclusion …………………………………………………………………..15
Bibliografia ………………………………………………………………… 16

2
Introducción

En un sistema informático se ejecutan de forma concurrente múltiples procesos que,


normalmente, no son independientes, sino que compiten en el uso exclusivo de recursos y
se comunican y sincronizan entre sí. El sistema operativo debe encargarse de asegurar que
estas interacciones se llevan a cabo apropiadamente, proporcionando la sincronización
requerida por las mismas

Las necesidades de algunos procesos pueden entrar en conflicto entre sí provocando que
estos se bloqueen permanentemente. Esta situación se denomina interbloqueo, se trata de
un problema general ya identificado en la década de los sesenta del siglo XX y estudiado
ampliamente desde entonces. El interbloqueo es una anomalía que puede ocurrir durante la
ejecución de procesos concurrentes debido a la competencia por los recursos.
Si bien es cierto que prácticamente ningún sistema operativo real incorpora mecanismos de
tratamiento de interbloqueo, esto es debido a una cuestión de la pérdida de rendimiento
que conlleva su tratamiento para la baja probabilidad que hay de que ocurra. En un sistema
operativo ideal, sin embargo, sí deberían incluirse mecanismos para su tratamiento, dado
que existen y son bien conocidos.

El interbloqueo es un problema que afecta a procesos concurrentes que utilizan recursos en


un sistema.
Los procesos solicitan recursos al sistema y los liberan cuando ya no los necesitan. Un
recurso puede estar disponible o bien asignado a algún proceso.

Existen cuatro condiciones para considerarse un interbloqueo, las cuales mencionaremos en


el desarrollo del trabajo, así como el tratamiento y la prevención de los mismos.

3
Introducción a los interbloqueos
El interbloqueo se puede definir formalmente de la siguiente manera: “Un conjunto de procesos se
encuentra en un interbloqueo si cada proceso en el conjunto está esperando un evento que sólo
puede ser ocasionado por otro proceso en el conjunto.” Debido a que todos los procesos están en
espera, ninguno de ellos producirá alguno de los eventos que podrían despertar a cualquiera de los
otros miembros del conjunto, y todos los procesos seguirán esperando para siempre

Interbloqueo de Recursos

En la mayoría de los casos, el evento por el que cada proceso espera es la liberación de algún recurso
que actualmente es poseído por otro miembro del conjunto. En otras palabras, cada miembro del
conjunto de procesos en interbloqueo está esperando un recurso que posee un proceso en
interbloqueo. Ninguno de los procesos se puede ejecutar, ninguno de ellos puede liberar recursos y
ninguno puede ser despertado. El número de procesos y el número de cualquier tipo de recursos
poseídos y solicitados es irrelevante. Este resultado se aplica a cualquier tipo de recurso, tanto de
hardware como de software.

Condiciones para los interbloqueos de recursos

• Condición de exclusión mutua. Cada recurso se asigna en un momento dado a sólo un


proceso, o está disponible.
• Condición de contención y espera. Los procesos que actualmente contienen recursos que se
les otorgaron antes pueden solicitar nuevos recursos.
• Condición no apropiativa. Los recursos otorgados previamente no se pueden quitar a un
proceso por la fuerza. Deben ser liberados de manera explícita por el proceso que los
contiene.
• Condición de espera circular. Debe haber una cadena circular de dos o más procesos, cada
uno de los cuales espera un recurso contenido por el siguiente miembro de la cadena.

Las cuatro condiciones deben estar presentes para que ocurra un interbloqueo. Si una de ellas está
ausente, no es posible el interbloqueo de recursos.

Modelado de interbloqueos

Los gráficos tienen dos tipos de nodos: procesos, que se muestran como círculos, y recursos, que se
muestran como cuadros. Un arco dirigido de un nodo de recurso (cuadro) a un nodo de proceso
(círculo) significa que el recurso fue solicitado previamente por, y asignado a, y actualmente es
contenido por ese proceso.

En la figura 6-3(a), el recurso R está asignado actualmente al proceso A.

4
Un arco dirigido de un proceso a un recurso significa que el proceso está actualmente bloqueado, en
espera de ese recurso. En la figura 6-3(b), el proceso B espera al recurso S. En la figura 6-3(c)
podemos ver un interbloqueo: el proceso C está esperando al recurso T, que actualmente es
contenido por el proceso D. El proceso D no va a liberar al recurso T debido a que está esperando el
recurso U, contenido por C. Ambos procesos esperarán para siempre. Un ciclo en el gráfico indica
que hay un interbloqueo que involucra a los procesos y recursos en el ciclo (suponiendo que hay un
recurso de cada tipo). En este ejemplo, el ciclo es C-T-D-U-C

Ahora veamos un ejemplo de cómo se pueden utilizar los gráficos de recursos. Imagine que tenemos
tres procesos A, B y C, y tres recursos R, S y T. Las peticiones y liberaciones de los tres procesos se
proporcionan en las figuras 6-4(a) a (c). El sistema operativo es libre de ejecutar cualquier proceso
desbloqueado en cualquier momento, por lo que podría optar por ejecutar A hasta que terminara
todo su trabajo, después B hasta que completara y por último C. Este orden no produce

5
interbloqueos (debido a que no hay competencia por los recursos), pero tampoco tiene paralelismo.
Además de solicitar y liberar recursos, los procesos realizan cálculos y operaciones de E/S. Cuando
los procesos se ejecutan en forma secuencial, no hay posibilidad de que mientras un proceso espera
la E/S, otro pueda utilizar la CPU. Por ende, ejecutar los procesos estrictamente en forma secuencial
puede no ser óptimo. Por otra parte, si ninguno de los procesos realiza operaciones de E/S, es mejor
el algoritmo del trabajo más corto primero que el algoritmo por turno rotatorio (round-robin), por lo
que en ciertas circunstancias tal vez lo mejor sea ejecutar todos los procesos en forma secuencial.
Ahora vamos a suponer que los procesos realizan tanto operaciones de E/S como cálculos, por lo
que el algoritmo por turno rotatorio es un algoritmo de programación razonable. Las peticiones de
recursos podrían ocurrir en el orden de la figura 6-4(d). Si estas seis solicitudes se llevan a cabo en
ese orden, los seis gráficos de recursos resultantes se muestran en las figuras 6-4(e) a (j). Después de
haber realizado la petición 4, A se bloquea en espera de S, como se muestra en la figura 6-4(h). En
los siguientes dos pasos B y C también se bloquean, lo que en última instancia conduce a un ciclo y al
interbloqueo de la figura 6-4(j). Sin embargo, y como ya hemos mencionado, el sistema operativo no
tiene que ejecutar los procesos en un orden especial. En particular si al otorgar una petición
específica se puede producir un interbloqueo, el sistema operativo simplemente puede suspender el
proceso sin otorgar la solicitud (es decir, no sólo programar el proceso) hasta que sea seguro. En la
figura 6-4, si el sistema operativo supiera acerca del interbloqueo inminente, podría suspender a B
en vez de otorgarle el recurso S. Al ejecutar sólo A y C, obtendríamos las peticiones y liberaciones de
la figura 6-4(k) en vez de la figura 6.4(d). Esta secuencia produce los gráficos de recursos de las
figuras 6-4(l) a (q), que no producen un interbloqueo. Después del paso (q), se puede otorgar el
recurso S al proceso B, debido a que A ha terminado y C tiene todo lo que necesita. Aun si B se
hubiera bloqueado al solicitar a T, no puede ocurrir un interbloqueo. B sólo esperará hasta que C
termine

En general, se utilizan cuatro estrategias para lidiar con los interbloqueos

• Sólo ignorar el problema. Tal vez si usted lo ignora, él lo ignorará a usted.


• Detección y recuperación. Dejar que ocurran los interbloqueos, detectarlos y tomar acción.
• Evitarlos en forma dinámica mediante la asignación cuidadosa de los recursos.
• Prevención, al evitar estructuralmente una de las cuatro condiciones requeridas.

El algoritmo del avestruz

El método más simple es el algoritmo del avestruz: meta su cabeza en la arena y pretenda que no
hay ningún problema. Las personas reaccionan a esta estrategia de diversas formas. Los
matemáticos la encuentran totalmente inaceptable y dicen que los interbloqueos se deben prevenir
a toda costa; los ingenieros preguntan con qué frecuencia se espera el problema, con qué frecuencia
falla el sistema por otras razones y qué tan grave es un interbloqueo. Si ocurren interbloqueos en
promedio de una vez cada cinco años, pero los fallos del sistema debido al hardware, errores del
compilador y errores en el sistema operativo ocurren una vez por semana, la mayoría de los
ingenieros no estarán dispuestos a reducir considerablemente el rendimiento por la conveniencia de
eliminar los interbloqueos.

Para que este contraste sea más específico, considere un sistema operativo que bloquea al proceso
llamador cuando no se puede llevar a cabo una llamada al sistema open en un dispositivo físico,
como una unidad de CD-ROM o una impresora, debido a que el dispositivo está muy ocupado. Por lo
general es responsabilidad del driver (controlador) de dispositivos decidir qué acción tomar bajo
tales circunstancias. Bloquear o devolver una clave de error son dos posibilidades obvias. Si un
proceso abre exitosamente la unidad de CD-ROM y otro la impresora, y después cada proceso trata

6
de abrir el otro recurso y se bloquea en el intento, tenemos un interbloqueo. Pocos sistemas
actuales detectarán esto.

Detección y Recuperación de un interbloqueo

Detección de interbloqueos con un recurso de cada tipo

Vamos a empezar con el caso más simple: sólo existe un recurso de cada tipo. Dicho sistema podría
tener un escáner, un grabador de CD, un trazador (plotter) y una unidad de cinta, pero no más que
un recurso de cada clase. En otras palabras, estamos excluyendo los sistemas con dos impresoras
por el momento. Más adelante lidiaremos con ellos, usando un método distinto.

Para un sistema así, podemos construir un gráfico de recursos. Si este gráfico contiene uno o más
ciclos, existe un interbloqueo. Cualquier proceso que forme parte de un ciclo está en interbloqueo.
Si no existen ciclos, el sistema no está en interbloqueo. Considere un sistema con siete procesos, A a
G, y seis recursos, R a W. El estado de cuáles recursos está contenido por algún proceso y cuáles
están siendo solicitados es el siguiente:

1. El proceso A contiene a R y quiere a S.

2. El proceso B no contiene ningún recurso, pero quiere a T.

3. El proceso C no contiene ningún recurso, pero quiere a S.

4. El proceso D contiene a U y quiere a S y a T.

5. El proceso E contiene a T y quiere a V.

6. El proceso F contiene a W y quiere a S.

7. El proceso G contiene a V y quiere a U

“¿Está este sistema en interbloqueo y, de ser así, cuáles procesos están involucrados?”. Para
responder a esta pregunta podemos construir el gráfico de recursos de la figura 6-5(a). Este gráfico
contiene un ciclo, que se puede ver mediante una inspección visual. El ciclo se muestra en la figura
6-5(b). De este ciclo podemos ver que los procesos D, E y G están en interbloqueo. Los procesos A, C
y F no están en interbloqueo debido a que S puede asignarse a cualquiera de ellos, que a su vez
termina y lo devuelve.

7
Aunque es relativamente fácil distinguir los procesos en interbloqueo a simple vista a partir de un
sencillo gráfico, para usar este método en sistemas reales necesitamos un algoritmo formal para la
detección de interbloqueos. Hay muchos algoritmos conocidos para detectar ciclos en gráficos
dirigidos. A continuación, veremos un algoritmo simple que inspecciona un gráfico y termina al
haber encontrado un ciclo, o cuando ha demostrado que no existe ninguno. Utiliza cierta estructura
dinámica de datos: L, una lista de nodos, así como la lista de arcos. Durante el algoritmo, los arcos se
marcarán para indicar que ya han sido inspeccionados, para evitar repetir inspecciones.

El algoritmo opera al llevar a cabo los siguientes pasos, según lo especificado:

1. Para cada nodo N en el gráfico, realizar los siguientes cinco pasos con N como el nodo inicial.

2. Inicializar L con la lista vacía y designar todos los arcos como desmarcados.

3. Agregar el nodo actual al final de L y comprobar si el nodo ahora aparece dos veces en L.

Si lo hace, el gráfico contiene un ciclo (listado en L) y el algoritmo termina.

4. Del nodo dado, ver si hay arcos salientes desmarcados. De ser así, ir al paso 5; en caso contrario, ir
al paso 6.

5. Elegir un arco saliente desmarcado al azar y marcarlo. Después seguirlo hasta el nuevo nodo
actual e ir al paso 3.

6. Si este nodo es el inicial, el gráfico no contiene ciclos y el algoritmo termina. En caso contrario,
ahora hemos llegado a un punto muerto. Eliminarlo y regresar al nodo anterior; es decir, el que
estaba justo antes de éste, hacerlo el nodo actual e ir al paso 3.

Lo que hace este algoritmo es tomar cada nodo en turno, como la raíz de lo que espera sea un árbol,
y realiza una búsqueda de un nivel de profundidad en él. Si alguna vez regresa a un nodo que ya se
haya encontrado, entonces ha encontrado un ciclo. Si agota todos los arcos desde cualquier nodo
dado, regresa al nodo anterior. Si regresa hasta la raíz y no puede avanzar más, el subgráfico que se
puede alcanzar desde el nodo actual no contiene ciclos. Si esta propiedad se aplica para todos los
nodos, el gráfico completo está libre de ciclos, por lo que el sistema no está en interbloqueo.

8
Detección del interbloqueo con varios recursos de cada tipo

Cuando existen varias copias de algunos de los recursos, se necesita un método distinto para
detectar interbloqueos. Ahora presentaremos un algoritmo basado en matrices para detectar
interbloqueos entre n procesos, de P1 a Pn. Hagamos que el número de clases de recursos sea m,
con E1 recursos de la clase 1, E2 recursos de la clase 2 y en general, Ei recursos de la clase i (1 ≤ i ≤
m). E es el vector de recursos existentes. Este vector proporciona el número total de instancias de
cada recurso en existencia.

En cualquier instante, algunos de los recursos están asignados y no están disponibles. Hagamos que
A sea el vector de recursos disponibles, donde Ai proporciona el número de instancias del recurso i
que están disponibles en un momento dado (es decir, sin asignar). Si ambas de nuestras unidades de
cinta están asignadas, A1 será 0.

Ahora necesitamos dos arreglos: C, la matriz de asignaciones actuales y R, la matriz de peticiones. La


i-ésima fila de C nos indica cuántas instancias de cada clase de recurso contiene Pi en un momento
dado. Así Cij es el número de instancias del recurso j que están contenidas por el proceso i. De
manera similar, Rij es el número de instancias del recurso j que desea Pi.

Sí agregamos todas las instancias del recurso j que se han asignado, y para ello agregamos todas las
instancias disponibles, el resultado es el número de instancias existentes de esa clase de recursos.

El algoritmo de detección de interbloqueos se basa en la comparación de vectores. Vamos a definir


la relación A ≤ B en dos vectores A y B para indicar que cada elemento de A es menor o igual que el
elemento correspondiente de B. En sentido matemático A ≤ B se aplica sí, y sólo si Ai ≤ Bi para 1 ≤ i ≤
m.

Al principio, se dice que cada proceso está desmarcado. A medida que el algoritmo progrese se
marcarán los procesos, indicando que pueden completarse y, por ende, no están en interbloqueo.

Cuando el algoritmo termine, se sabe que cualquier proceso desmarcado está en interbloqueo. Este
algoritmo supone un escenario del peor caso: todos los procesos mantienen todos los recursos
adquiridos hasta que terminan.

Recuperación de un interbloqueo

Recuperación por medio de apropiación

En algunos casos puede ser posible quitar temporalmente un recurso a su propietario actual y
otorgarlo a otro proceso. En muchos casos se puede requerir intervención manual, en especial en los
sistemas operativos de procesamiento por lotes que se ejecutan en mainframes.

Por ejemplo, para quitar una impresora láser a su propietario, el operador puede recolectar todas las
hojas ya impresas y colocarlas en una pila. Después se puede suspender el proceso (se marca como
no ejecutable). En este punto, la impresora se puede asignar a otro proceso. Cuando ese proceso
termina, la pila de hojas impresas se puede colocar de vuelta en la bandeja de salida de la impresora
y se puede reiniciar el proceso original.

La habilidad de quitar un recurso a un proceso, hacer que otro proceso lo utilice y después
regresarlo sin que el proceso lo note, depende en gran parte de la naturaleza del recurso. Con
frecuencia es difícil o imposible recuperarse de esta manera.

9
Recuperación a través del retroceso

Si los diseñadores de sistemas y operadores de máquinas saben que es probable que haya
interbloqueos, pueden hacer que los procesos realicen puntos de comprobación en forma periódica.
Realizar puntos de comprobación en un proceso significa que su estado se escribe en un archivo
para poder reiniciarlo más tarde.

El punto de comprobación no sólo contiene la imagen de la memoria, sino también el estado del
recurso; en otras palabras, qué recursos están asignados al proceso en un momento dado. Para que
sean más efectivos, los nuevos puntos de comprobación no deben sobrescribir a los anteriores, sino
que deben escribirse en nuevos archivos, para que se acumule una secuencia completa a medida
que el proceso se ejecute.

Cuando se detecta un interbloqueo, es fácil ver cuáles recursos se necesitan. Para realizar la
recuperación, un proceso que posee un recurso necesario se revierte a un punto en el tiempo antes
de que haya adquirido ese recurso, para lo cual se inicia uno de sus puntos de comprobación
anteriores. Se pierde todo el trabajo realizado desde el punto de comprobación. En efecto, el
proceso se restablece a un momento anterior en el que no tenía el recurso, que ahora se asigna a
uno de los procesos en interbloqueo. Si el proceso reiniciado trata de adquirir el recurso de nuevo,
tendrá que esperar hasta que vuelva a estar disponible.

Recuperación a través de la eliminación de procesos

La forma más cruda y simple de romper un interbloqueo es eliminar uno o más procesos. Una
posibilidad es eliminar a uno de los procesos en el ciclo. Con un poco de suerte, los demás procesos
podrán continuar. Si esto no ayuda, se puede repetir hasta que se rompa el ciclo.

De manera alternativa, se puede elegir como víctima a un proceso que no esté en el ciclo, para
poder liberar sus recursos. En este método, el proceso a eliminar se elige con cuidado, debido a que
está conteniendo recursos que necesita cierto proceso en el ciclo.

Donde sea posible, es mejor eliminar un proceso que se pueda volver a ejecutar desde el principio
sin efectos dañinos. Si se elimina a mitad del proceso, la primera ejecución no tiene influencia sobre
la segunda.

Por otra parte, un proceso que actualiza una base de datos no siempre se puede ejecutar una
segunda vez en forma segura. Si el proceso agrega 1 a algún campo de una tabla en la base de datos,
al ejecutarlo una vez, después eliminarlo y volverlo a ejecutar de nuevo, se agregará 2 al campo, lo
cual es incorrecto.

10
Cómo prevenir interbloqueos

Habiendo visto que evitar los interbloqueos es algo imposible, debido a que se requiere información
sobre las peticiones futuras, ¿cómo evitan los sistemas reales el interbloqueo? La respuesta es volver
a las cuatro condiciones establecidas por Coffman y colaboradores (1971) podemos asegurar que por
lo menos una de estas condiciones nunca se cumpla, entonces los interbloqueos serán
estructuralmente imposibles

Cómo atacar la condición de exclusión mutua

Primero vamos a atacar la condición de exclusión mutua. Si ningún recurso se asignara de manera
exclusiva a un solo proceso, nunca tendríamos interbloqueos. No obstante, es igual de claro que al
permitir que dos procesos escriban en la impresora al mismo tiempo se producirá un caos. Al colocar
la salida de la impresora en una cola de impresión, varios procesos pueden generar salida al mismo
tiempo. En este modelo, el único proceso que realmente solicita la impresora física es el demonio de
impresión.

Si el demonio se programa para imprimir aún y cuando toda la salida esté en una cola de impresión,
la impresora podría permanecer inactiva si un proceso de salida decide esperar varias horas después
de la primera ráfaga de salida. Por esta razón, los demonios comúnmente se programan para
imprimirse sólo hasta después que esté disponible el archivo de salida completo. ¿Qué ocurriría si dos
procesos llenaran cada uno una mitad del espacio de la cola de impresión disponible con datos de
salida y ninguno terminara de producir su salida completa? En este caso tendríamos dos procesos en
los que cada uno ha terminado una parte, pero no toda su salida, y no pueden continuar.

Sin embargo, hay una idea aquí, que se aplica con frecuencia: evite asignar un recurso cuando no sea
absolutamente necesario, y trate de asegurarse que la menor cantidad posible de procesos reclamen
ese recurso.

Cómo atacar la condición de contención y espera

La segunda condición establecida por Coffman y colaboradores se ve más prometedora. Si podemos


evitar que los procesos que contienen recursos esperen por más recursos, podemos eliminar los
interbloqueos. Una forma de lograr esta meta es requerir que todos los procesos soliciten todos sus
recursos antes de empezar su ejecución. Si todo está disponible, al proceso se le asignará lo que
necesite y podrá ejecutarse hasta completarse.

Un problema con este método es que muchos procesos no saben cuántos recursos necesitarán hasta
que hayan empezado a ejecutarse. Otro problema es que los recursos no se utilizarán de una manera
óptima con este método.

Una manera ligeramente distinta de romper la condición de contención y espera es requerir que un
proceso que solicita un recurso libere temporalmente todos los recursos que contiene en un momento
dado. Después puede tratar de obtener todo lo que necesite a la vez.

Cómo atacar la condición no apropiativa

También es posible atacar la tercera condición. Si a un proceso se le ha asignado la impresora y está a


la mitad de imprimir su salida, quitarle la impresora a la fuerza debido a que el trazador que necesita
no está disponible es algo engañoso como máximo, e imposible en el peor caso. Sin embargo, ciertos
recursos se pueden virtualizar para evitar esta situación. Al colocar en una cola de impresión en el
disco la salida de la impresora y permitir que sólo el demonio de impresión tenga acceso a la impresora

11
real, se eliminan los interbloqueos que involucran a la impresora, aunque se crea uno para el espacio
en disco. No obstante, con los discos grandes es muy improbable quedarse sin espacio.

Sin embargo, no todos los recursos se pueden virtualizar de esta manera.

Cómo atacar la condición de espera circular

Sólo queda una condición. La espera circular se puede eliminar de varias formas. Una de ellas es
simplemente tener una regla que diga que un proceso tiene derecho sólo a un recurso en cualquier
momento. Si necesita un segundo recurso, debe liberar el primero. Para un proceso que necesita
copiar un enorme archivo de una cinta a una impresora, esta restricción es inaceptable.

Otra manera de evitar es proporcionar una numeración global de todos los recursos, como se muestra
en la figura 6-13(a). Ahora la regla es ésta: los procesos pueden solicitar recursos cada vez que quieran,
pero todas las peticiones se deben realizar en orden numérico.

Con esta regla, el gráfico de asignación de recursos nunca puede tener ciclos . Veamos por qué es esto
cierto para el caso de dos procesos, en la figura 6-13(b). Podemos obtener un interbloqueo sólo si A
solicita el recurso j y B solicita el recurso i. Suponiendo que i y j sean recursos distintos, tendrán
diferentes números. Si i > j, entonces A no puede solicitar a j debido a que es menor de lo que ya tiene.
Si i < j, entonces B no puede solicitar a i debido a que es menor de lo que ya tiene. De cualquier forma,
el interbloqueo es imposible.

Una variación menor de este algoritmo es retirar el requerimiento de que los recursos se adquieran
en una secuencia cada vez más estricta, y simplemente insistir que ningún proceso puede solicitar un
recurso menor del que ya contiene.

Aunque el ordenamiento numérico de los recursos elimina el problema de los interbloqueos, puede
ser imposible encontrar un ordenamiento que satisfaga a todos.

Los diversos métodos para evitar el interbloqueo se sintetizan en la figura 6-14.

Condición Método
Exclusión mutua Poner todo en la cola de impresión
Contención y espera Solicitar todos los recursos al principio
No apropiativa Quitar los recursos
Espera circular Ordenar los recursos en forma numérica

12
Bloqueo de dos fases

El protocolo de bloqueo de dos fases se utiliza para garantizar que las transacciones se serialicen. En
el protocolo de bloqueo de dos fases, cada transacción debe emitir todas las solicitudes de bloqueo
antes de que pueda emitir cualquier solicitud de desbloqueo.
En la primera fase, el proceso trata de bloquear todos los registros que necesita, uno a la vez. Si
tiene éxito pasa a la segunda fase, realizando sus actualizaciones y liberando los bloqueos. No se
realiza ningún trabajo real en la primera fase.
Si durante la primera fase se necesita cierto registro que ya esté bloqueado, el proceso sólo libera
todos sus bloqueos e inicia la primera fase desde el principio en ciertas versiones del bloqueo de dos
fases, no hay liberación y reinicio si se encuentra un registro bloqueado durante la primera fase. En
estas versiones puede ocurrir un interbloqueo. Sin embargo, esta estrategia no es aplicable en
general. Por ejemplo, en los sistemas de tiempo real y los sistemas de control de procesos, no es
aceptable sólo terminar un proceso a la mitad debido a que un recurso no está disponible, y
empezar todo de nuevo. Tampoco es aceptable iniciar de nuevo si el proceso ha leído o escrito
mensajes en la red, actualizado archivos o cualquier otra cosa que no se pueda repetir con
seguridad.
El algoritmo funciona sólo en aquellas situaciones en donde el programador ha ordenado las cosas
con mucho cuidado, para que el programa se pueda detener en cualquier punto durante la primera
fase y luego se reinicie. Muchas aplicaciones no se pueden estructurar de esta forma.

Interbloqueos de comunicaciones

Los interbloqueos de comunicación no se pueden evitar mediante el ordenamiento de recursos (ya


que no hay ninguno), ni se puede evitar mediante una programación cuidadosa (ya que no hay
momentos en los que se puede posponer una petición). Por fortuna hay otra técnica que por lo
general se puede utilizar para romper los interbloqueos de comunicación: los tiempos de espera. En
la mayoría de los sistemas de comunicación de red, cada vez que se envía un mensaje del que se
espera una respuesta, también se inicia un temporizador. Si el temporizador termina su conteo
antes de que llegue la respuesta, el emisor del mensaje asume que éste se ha perdido y lo envía de
nuevo (una y otra vez, si es necesario). De esta forma se evita el interbloqueo. Desdé luego que, si el
mensaje original no se perdió, pero la respuesta simplemente se retrasó, el receptor destinado
puede recibir el mensaje dos o más veces, tal vez con consecuencias indeseables. Por fortuna hay
otra técnica que por lo general se puede utilizar para romper los interbloqueos de comunicación: los
tiempos de espera. En la mayoría de los sistemas de comunicación de red, cada vez que se envía un
mensaje del que se espera una respuesta, también se inicia un temporizador. Si el temporizador
termina su conteo antes de que llegue la respuesta, el emisor del mensaje asume que éste se ha
perdido y lo envía de nuevo (una y otra vez, si es necesario). De esta forma se evita el interbloqueo.

No todos los interbloqueos ocurren en los sistemas de comunicaciones, ni todas las redes son
interbloqueos de comunicación. Aquí también pueden ocurrir interbloqueos de recursos. Por
ejemplo, considere la red de la figura

13
Un interbloqueo de recursos de red.

Cuando llega un paquete a un enrutador proveniente de uno de sus hosts, se coloca en un búfer
para transmitirlo a continuación a otro enrutador, y después a otro hasta que llega al destino. Estos
búferes son recursos y hay un número finito de ellos. Cada enrutador sólo tiene ocho búferes
Suponga que todos los paquetes en el enrutador A necesitan ir a B, que todos los paquetes en B
necesitan ir a C, que todos los paquetes en C necesitan ir a D y todos los paquetes en D necesitan ir a
A. Ningún paquete se puede mover debido a que no hay búfer al otro extremo y tenemos un
interbloqueo de recursos clásico, aunque a la mitad de un sistema de comunicaciones.

Bloqueo activo

En ciertas situaciones se utiliza el sondeo (ocupado en espera). Esta estrategia se utiliza a menudo
cuando se va a usar la exclusión mutua por un tiempo muy corto, y la sobrecarga de la suspensión es
grande en comparación con realizar el trabajo. Ahora imagine un par de procesos que utilizan dos
recursos, como se muestra en la figura

Cada uno necesita dos recursos y ambos utilizan la primitiva de sondeo entrar_region para tratar de
adquirir los bloqueos necesarios. Si falla el intento, el proceso sólo intenta otra vez. si el proceso A se
ejecuta primero y adquiere el recurso 1, y después se ejecuta el proceso 2 y adquiere el recurso 2,
sin importar quién se ejecute a continuación, no progresará más, pero ninguno de los procesos se
bloqueará. Sólo utiliza su quantum de CPU una y otra vez sin progresar, pero sin bloquearse
tampoco. Por ende, no tenemos un interbloqueo.

Inanición

Se produce cuando algún proceso dentro del sistema no puede satisfacer su necesidad de recursos
debido a que otros procesos lo están utilizando continuamente. Este término básicamente se
presenta en algoritmos que determinan asignación por importancia o asignación por tamaño. En los
sistemas operativos las tareas dejan de llegar allí puede haber tareas poco importantes pero que
esperan su turno aun así las tareas más importantes que van llegando se van asignando. Como las
tareas nunca dejan de llegar existen trabajos poco o muy importantes a los cuales se les permitirá el
uso de recursos.
La inanición se puede evitar mediante el uso de una política de asignación de recursos del tipo
“primero en llegar, primero en ser atendido”. Con este método, el proceso que espere más tiempo
será el que se atienda primero. A su debido tiempo, cualquier proceso dado se convertirá en el más
antiguo y, por ende, obtendrá el recurso que necesita.

14
Conclusión
El problema del interbloqueo no se circunscribe específicamente al mundo de la
informática, suelen aparecer en muchos otros ámbitos, incluyendo la vida cotidiana.
El interbloqueo es un problema potencial en cualquier sistema operativo. Ocurre cuando
todos los miembros de un conjunto de procesos se bloquean en espera de un evento que
sólo otros miembros del conjunto pueden ocasionar. Esta situación hace que todos los
procesos esperen para siempre. Comúnmente, el evento que los procesos esperan es la
liberación de algún recurso contenido por otro miembro del conjunto.
Otra situación en la que es posible el interbloqueo se da cuando un conjunto de procesos
de comunicación está a la espera de un mensaje, y el canal de comunicación está vacío sin
que haya tiempos de espera pendientes.
Se puede evitar al llevar la cuenta de cuáles estados son seguros y cuáles son inseguros. Un
estado seguro es uno en el que existe una secuencia de eventos que garantizan que todos
los procesos pueden terminar; un estado inseguro no tiene dicha garantía
Se puede prevenir estructuralmente, al construir el sistema de tal forma que nunca pueda
ocurrir por diseño. También se puede prevenir al enumerar todos los recursos, y hacer que
los procesos los soliciten en orden estrictamente ascendente.
Esconder la cabeza y hacer como si nada pasara no es una solución para este problema, se
debe buscar el proceso adecuado para la prevención del bloqueo e inmediatamente, una
vez localizado un bloqueo, borrarlo para evitar nuevos inconvenientes.

15
Bibliografía

• https://es.wikipedia.org › wiki › Bloqueo_mutuo

• http://www.cs.uns.edu.ar › data › apuntes

• Tanenbaum, Sistemas Operativos Modernos, 3era edición

16

También podría gustarte