Sei sulla pagina 1di 39

REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA SISTEMAS OPERATIVO – SECCIÓN 01 CIUDAD GUAYANA – ESTADO BOLÍVAR

– SECCIÓN 01 CIUDAD GUAYANA – ESTADO BOLÍVAR PROFESOR: ANDRÉS CANIUMILLA ALUMNOS: BRICEÑO, KENDY C.I.

PROFESOR:

ANDRÉS CANIUMILLA

ALUMNOS:

BRICEÑO, KENDY C.I. 19.534.700 FLORES, LUÍS C.I. 17.113.654

CIUDAD GUAYANA, JULIO DE 2010

INDICE

Interbloqueo………………………………………………………………………

3

Recursos………………………………………………………………………….

4

Recursos Reutilizables…………………………………………………

4

Recursos Consumibles…………………………………………………

4

Recursos Compartidos…………………………………………………

4

Recursos con único ejemplar o con múltiples…………………

5

Recursos expropiables o no…………………………………………

5

Ejemplos gráficos……………………………………………………………….

5

Grafo de asignación de recursos…………………………………………….

8

Condiciones para el interbloqueo……………………………………………

10

Posibilidad del interbloqueo…………………………………………………

11

Existencia del interbloqueo……………………………………………………

12

Prevención del interbloqueo…………………………………………………

18

Predicción del interbloqueo………………………………………………

22

Recuperación del interbloqueo……………………………………………….

28

Mecanismo para evitar el interbloqueo……………………………………

31

Estados seguros e inseguros…………………………………………………

36

2

INTERBLOQUEO (INANICIÓN Ó DEADLOCK)

Es el BLOQUEO permanente de un conjunto de procesos que compiten

por los recursos del sistema o bien se comunican entre ellos.

La inanición es un problema relacionado con los sistemas de multitarea,

donde a un proceso se le deniega siempre el acceso a los recursos

compartido. Donde sin estos recursos no se puede finalizar la instrucción.

La inanición es una situación similar al interbloqueo, pero las causas

son diferentes. En el interbloqueo, dos procesos o dos hilos de ejecución

llegan a un punto muerto cuando cada uno de ellos necesita un recurso que

es ocupado por el otro. En cambio, en este caso, uno o más procesos están

esperando recursos ocupados por otros procesos que no se encuentran

necesariamente en ningún punto muerto.

El interbloqueo se puede referenciar de la siguiente manera:

DEADLOCK

RECURSOS

ABRAZO

MORTAL

BLOQUEO

MUTUO

En un sistema informático donde interviene el interbloqueo se puede

prsentar diferentes recursos de acuerdo a los siguientes aspectos:

1.- Existes recursos después que un proceso las usas, que serían los

recursos reutilizables, o aquellos que desaparecen una vez utilizado.

2.- Asimismo, existen procesos que pueden compartir el uso de los

recursos usándolos de modo especial.

3.- De la misma forma hay ejemplar de cada recurso o múltiples, e

igualmente existe la posibilidad de expropiar el recurso que lo esta

utilizando.

3

- RECURSOS REUTILIZABLES: también llamados reutilizables, estos se llaman así ya que en el momento en que un proceso los use, puede quedar disponible para que otro proceso lo utilice, por lo que no hace tomar en cuenta que la vida del recurso es independiente de su utilización, es decir:

- Puede ser que exista desde el principio (en el caso de que sea un recurso físico).

- De la misma forma puede ser que ya esté creado y se destruya explícitamente (ejemplo de ello puede ser un fichero).

- RECURSOS CONSUMIBLES: estos recursos se caracterizan por dejar

de existir una vez que se utilicen, es decir, un proceso genera o produce el recurso y el otro lo utiliza consumiéndolo. Dentro de esta categoría podemos mencionar lo siguiente:

- En esto se encuentran básicamente los recursos lógicos relacionados con la comunicación y sincronización de procesos.

- Como ejemplo de ello podemos considerar los mensajes, las señales, o los semáforos.

- RECURSOS COMPARTIDOS: Se ha estado suponiendo que cuando un proceso está usando los recursos, de esta forma ningún otro lo puede utilizar. Sin embargo esto no es para todos los recursos, es decir, algunos recursos pueden ser usados simultáneamente por varios procesos. Como ejemplo de los recursos compartidos podemos encontrar:

- Los ficheros pueden ser accedidos simultáneamente procesos.

4

en varios

- RECURSOS CON UNICO EJEMPLAR O CON MULTIPLES: se puede considerar que cada recurso es un es una entidad única. Pero en un sistema pueden existir múltiples ejemplares de un determinado recurso. Ejemplo de ello, podemos nombrar:

- Un sistema compuesto por cinco impresoras, cuando un proceso solicita una impresora, se le podría asignar cualquier unidad que esté disponible.

- RECURSOS EXPROPIABLES O NO: igualmente se podemos encontrar como estrategia para el tratamiento de los interbloqueo, es la revocación de algún recurso que se le asigna a un determinado proceso, mientra este está haciendo uso de él, se le pueda otorgar a otro proceso.

EJEMPLO GRÁFICOS.

él, se le pueda otorgar a otro proceso. EJEMPLO GRÁFICOS. EJEMPLO 1: Este ejemplo gráfico nos

EJEMPLO 1: Este ejemplo gráfico nos muestra de que forma, en cualquier sistema nos muestra como los procesos esperan que se le asigne un recurso, la programación de un sistema puede postergarse indefinidamente mientras otro recibe la atención del sistema.

recurso, la programación de un sistema puede postergarse indefinidamente mientras otro recibe la atención del sistema.

5

EJEMPLO 2: En la ilustración siguiente, la transacción T1 tiene una dependencia de la transacción

EJEMPLO 2: En la ilustración siguiente, la transacción T1 tiene una dependencia de la transacción T2 para el recurso de bloqueo de la tabla Part. Paralelamente, la transacción T2 tiene una dependencia de la transacción T1 para el recurso de bloqueo de la tabla Supplier. Puesto que estas dependencias forman un ciclo, hay un interbloqueo entre las transacciones T1 y T2.

Los interbloqueos también se pueden producir cuando se crean particiones en una tabla y el valor de LOCK_ESCALATION en ALTER TABLE se fija en AUTO. Cuando el valor de LOCK_ESCALATION es AUTO, la simultaneidad aumenta permitiendo a Database Engine (Motor de base de datos) bloquear las particiones de la tabla en el nivel HoBT en lugar de en el nivel TABLE. Sin embargo, cuando transacciones independientes mantienen bloqueos de partición en una tabla y desean un bloqueo en algún punto de la partición de otras transacciones, se produce un interbloqueo. Este tipo de interbloqueo se puede evitar asignando a LOCK_ESCALATION el valor TABLE; aunque este valor reducirá la simultaneidad obligando a las grandes actualizaciones de las particiones a esperar a que se produzca un bloqueo de la tabla.

obligando a las grandes actualizaciones de las particiones a esperar a que se produzca un bloqueo

6

EJEMPLO 3: En la ilustración siguiente, nos muestra una grafica de asignación y petición de

EJEMPLO 3: En la ilustración siguiente, nos muestra una grafica de asignación y petición de recursos.

EJEMPLO 3: En la ilustración siguiente, nos muestra una grafica de asignación y petición de recursos.

7

GRAFO DE ASIGNACIÓN DE RECURSOS

Los interbloqueos pueden describirse utilizando un grafo dirigido y bipartito G(N,A).

El cual consta de un conjunto de N nodos (vértices) y E arcos.

• 2 tipos de nodos

• 2 tipos de arcos

Procesos.

Recursos

2 tipos de nodos • 2 tipos de arcos Procesos. Recursos • Arco de solicitud .

Arco de solicitud. Es un arco que parte de un proceso Pi hacia un tipo de recurso Rj y se representa por Pi Rj (o (Pi, Rj)). Significa que el proceso Pi solicitó una instancia del recurso Rj y se encuentra esperándolo.

Arco de asignación. Es un arco que sale de un tipo de recurso Rj y se dirige a un proceso Pi (representado por Rj Pi o (Rj, Pi)). Significa que se ha asignado un ejemplar del tipo de recurso Rj al proceso Pi.

En cuanto a su implementación gráfica, se debe considerar:

- Cada proceso con un círculo y cada tipo de recurso con un rectángulo.

- Si de algún tipo de recurso existe más de un ejemplar, se representa cada uno con un punto dentro del rectángulo.

- Un arco de solicitud parte entonces de un rectángulo.

8

círculo y apunta a

un

- Un arco de asignación parte desde un punto dentro del rectángulo y

señala hacia un círculo.

Operación

Efecto en el grafo

Pi solicita un ejemplar del tipo Rj

Se inserta un arco de solicitud Pi Rj

Una instancia del recurso Rj se asigna al proceso Pi

El arco de solicitud Pi Rj se transforma instantáneamente en arco de asignación Rj Pi

El proceso Pi libera el recurso Rj

Se elimina el arco de asignación Rj Pi

proceso Pi libera el recurso Rj Se elimina el arco de asignación Rj → Pi Grafo
proceso Pi libera el recurso Rj Se elimina el arco de asignación Rj → Pi Grafo

Grafo de Asignación de Recursos

9

CONDICIONES PARA EL INTERBLOQUEO

En la política del sistema operativo, deben darse tres condiciones para que pueda producirse un interbloqueo:

1.- Condición de exclusión mutua: Cada recurso esta asignado a un único proceso o esta disponible.

2.- Condición de posesión y espera: Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos.

3.- Condición de no apropiación: Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso. El proceso que los posee debe liberarlos en forma explicita.

En la mayoría de los casos, estas condiciones son bastantes necesarias. La exclusión mutua hace falta para asegurar la consistencia de resultados y la integridad de la base de datos. De forma similar, la apropiación no se puede aplicar arbitrariamente y, cuando se encuentran involucrados recursos de datos, debe estar acompañada de un mecanismo de recuperación y reanulación, que devuelva un proceso y sus recursos a un estado previo adecuado, desde el que el proceso puede finalmente repetir sus acciones.

Puede no existir interbloqueo con solo estas tres condiciones. Para que se produzca interbloqueo, se necesita una cuarta condición:

4.- La condición de espera circular (o círculo vicioso de espera):

Debe existir una cadena circular de dos o más procesos, cada uno de los cuales espera un recurso poseído por el siguiente miembro de la cadena.

10

Las tres primeras condiciones son necesarias, pero no suficientes, para que exista interbloqueo. La cuarta condición es, en realidad, una consecuencia potencial de las tres primeras. Es decir, dado que se producen las tres primeras condiciones, puede ocurrir una secuencia de eventos que desemboque en un círculo vicioso de espera irresoluble. El círculo de espera de la condición 4 es irresoluble porque se mantienen las tres primeras condiciones. Las cuatro condiciones en conjunto constituyen una condición necesaria y suficiente para el interbloqueo.

POSIBILIDAD DE INTERBLOQUEO

Existen diversas posibilidades al momento de darse un interbloqueo, dentro de éstas encontrándose:

Posibilidad 1:

El proceso solicita todos los recursos necesarios antes de comenzar su ejecución.

- Pobre utilización de los recursos.

- Reducción del nivel de concurrencia.

Posibilidad 2:

El proceso solicita los recursos de forma incremental a lo largo de su ejecución, pero libera todos los recursos retenidos si se encuentra con una negativa.

- Menos exigente

- Los cambios hechos sobre la memoria o sobre ficheros pueden corromper el sistema si no se llevan a término.

11

- Pueden conducir a la postergación indefinida (o inanición) de algunos procesos que solicitan recursos muy utilizados.

EXISTENCIA DEL INTERBLOQUEO

El S. O. realiza lo siguiente:

Intenta detectar cuando han ocurrido.

Acciona para recuperarse después del hecho.

La detección del bloqueo es el proceso de:

Determinar si de hecho existe o no un bloqueo.

Identificar cuáles son los procesos y recursos implicados en el bloqueo.

Los algoritmos de detección de bloqueos implican cierta sobrecarga en tiempo de ejecución.

EXISTENCIA de interbloqueos de Forma “Un Recurso de Cada Tipo”

No se dispone de más de un objeto de cada clase de recurso.

Si la gráfica de recursos contuviera uno o más ciclos, existiría un bloqueo.

Cualquier proceso que forme parte de un ciclo está bloqueado; si no existen ciclos, el sistema no está bloqueado.

Ejemplo: sistema con 7 (siete) procesos (“A” a “G”) y 6 (seis) recursos (“R” a “W”):

La posesión de los recursos es la siguiente:

El proceso A posee a R y desea a S.

El proceso B no posee recurso alguno y desea a T.

El proceso C no posee recurso alguno y desea a S.

12

El proceso D posee a U y desea a S y a T.

El proceso E posee a T y desea a V.

El proceso F posee a W y desea a S.

El proceso G posee a V y desea a U.

La pregunta es: ¿está bloqueado este sistema y, en tal caso, cuáles son los procesos bloqueados?

La respuesta se obtiene mediante la gráfica de recursos: si la gráfica presenta un ciclo significa procesos bloqueados.

Se hace necesario un algoritmo formal para la detección de bloqueos que se pueda utilizar en los sistemas reales.

Ejemplo de algoritmo aplicable a cada nodo “N” de la gráfica:

1. Se considera a “N” como nodo inicial.

2. Se inicializan:

La estructura de datos “L” como una lista vacía.

Todos los arcos como no marcados.

3. Se añade el nodo activo al final de “L” y se verifica si el nodo aparece en “L” dos veces:

Si aparece dos veces existe un ciclo y el algoritmo termina.

4. Desde el nodo dado se verifica si existen arcos que salgan de dicho nodo y no estén marcados:

En caso afirmativo se va al paso 5.

En caso negativo se va al paso 6.

5. Se elige al azar un arco de salida no marcado y se le marca:

Luego se sigue este arco hasta el nuevo nodo activo y se regresa al paso 3.

13

6. Se ha llegado a un punto donde no se puede continuar:

Se regresa al nodo anterior, es decir al que estaba activo antes del actual.

Se señala de nuevo como nodo activo.

Se pasa al paso 3.

Si este nodo era el nodo inicial, la gráfica no contiene ciclos y el algoritmo termina.

La aplicación del algoritmo precedente al ejemplo anterior de gráfica dirigida es la siguiente:

Se parte de “R” y se inicializa “L” como la lista vacía.

Se añade “R” a la lista y se mueve a la única posibilidad, “A”.

Se añade “A” a la lista: L=[R,A].

Se pasa de “A” a “S”, quedando L=[R,A,S].

S” no tiene arcos que salgan de él, por lo que no se puede continuar y se regresa a “A”.

Ya que “A” no tiene arcos de salida no marcados se regresa a “R”, finalizando la inspección de “R”.

Se inicia nuevamente el algoritmo partiendo de “A”, siendo “L” otra vez la lista vacía.

La búsqueda termina rápidamente y se parte de “B”.

De “B” se siguen los arcos de salida hasta llegar a “D”, siendo L=[B,T,E,V,G,U,D].

Se efectúa una elección al azar.

Si se elige “S” llegamos a un punto sin salida y debemos regresar a “D”.

La segunda vez se elige “T” quedando L=[B,T,E,V,G,U,D,T] :

Se ha descubierto un ciclo y el algoritmo se detiene.

14

Existencia de Bloqueos de Forma “Varios Recursos de Cada Tipo”

Se considera un algoritmo basado en matrices para la detección de un bloqueo entre “n” procesos, “P 1 hasta “P n .

Se considera “m” el número de clases de recursos con:

E 1 recursos de la clase 1.

E 2 recursos de la clase 2.

E i recursos de la clase “i” (1 menor o igual que “i” menor o igual que

m”).

E” es el vector de recursos existentes.

En todo momento algunos de los recursos están asignados y por lo tanto no están disponibles.

Se considera un vector “A” de recursos disponibles:

A i indica el número de instancias disponibles del recurso “i ” ; se

refiere a recursos no asignados.

Se utilizan:

La matriz “C” de la asignación actual.

La matriz “R” de solicitudes.

El renglón i -ésimo de “C” indica el número de instancias de cada clase “P i

poseídas en ese momento.

Cij ” es el número de instancias del recurso“ j” deseadas por “P i ”.

Cada recurso está asignado o disponible, es decir que la suma de las instancias del recurso “j ” asignadas y el número de instancias disponibles es el número de instancias existentes de esa clase de recurso.

15

El algoritmo de detección de bloqueos se basa en la comparación de vectores:

Definimos que “A” es menor o igual que “B” si y solo si “A i es menor

o igual que “B i para “i” entre “0” y “m”, ambos inclusive.

Los procesos no están marcados al principio.

Al avanzar el algoritmo los procesos se marcarán:

Esto indica que pueden terminar su labor, ya que no están bloqueados.

Al concluir el algoritmo se sabe que los procesos no marcados estarán bloqueados.

Los pasos básicos del algoritmo de detección de bloqueos son los siguientes:

1. Se busca un proceso no marcado “P i , para el cual el i -ésimo

renglón de “R” sea menor que “A”.

2. Si se encuentra tal proceso, se suma el i -ésimo renglón de “C” a “A”, se marca el proceso y se regresa al paso 1.

3. Si no existe tal proceso, el algoritmo termina.

En el ejemplo tenemos 3 procesos y 4 clases de recursos).

El proceso 1 tiene 1 impresora.

El proceso 2 tiene 2 unidades de cinta y 1 unidad de CD rom.

El proceso 3 tiene 1 plotter y 2 impresoras.

16

La matriz “R” indica las necesidades de recursos adicionales.

El algoritmo de detección de bloqueos busca un proceso cuya solicitud de un recurso pueda ser satisfecha:

El proceso 1 no se puede satisfacer por no disponer de una unidad de cd rom.

El proceso 2 no se puede satisfacer por no disponer de una impresora.

El proceso 3 sí se puede satisfacer, por lo que se ejecuta, regresando en cierto momento sus recursos, lo que resulta en: A = (2 2 2 0).

Se ejecuta el proceso 2, el cual regresa sus recursos, obteniéndose: A = (4 2 2

1).

Se ejecuta el proceso restante: no existe bloqueo en el sistema.

Si se considera la siguiente variante:

El proceso 2 necesita 1 unidad de CD ROM, las 2 unidades de cinta y el plotter.

No se pueden satisfacer las 3 solicitudes y todo el sistema se bloquea.

Cuándo Buscar los Bloqueos

Una posibilidad es cada vez que se solicita un recurso, pero esto podría sobrecargar al sistema.

Otra posibilidad es verificar cada k minutos.

17

Otro criterio es verificar cuando el uso de la CPU baje de cierto valor fijo:

Si se bloquean suficientes procesos:

Existirán pocos procesos en ejecución.

La CPU estará inactiva con más frecuencia.

PREVENCIÓN DEL INTERBLOQUEO

Si se puede garantizar que al menos una de las cuatro condiciones de Coffman para el bloqueo nunca se satisface, entonces los bloqueos serán imposibles por razones estructurales (enunciado de Havender).

Havender sugirió las siguientes estrategias para evitar varias de las condiciones de bloqueo:

Cada proceso:

Deberá pedir todos sus recursos requeridos de una sola vez.

No podrá proceder hasta que le hayan sido asignados.

Si a un proceso que mantiene ciertos recursos se le niega una nueva petición, este proceso deberá:

Liberar sus recursos originales.

En caso necesario, pedirlos de nuevo junto con los recursos adicionales.

Se impondrá la ordenación lineal de los tipos de recursos en todos los procesos:

Si a un proceso le han sido asignados recursos de un tipo dado, en lo sucesivo solo podrá pedir aquellos recursos de los tipos que siguen en el ordenamiento.

Havender no presenta una estrategia contra el uso exclusivo de recursos por parte de los procesos, pues se desea permitir el uso de recursos dedicados.

18

Prevención de la Condición de Exclusión Mutua

Si ningún recurso se asignara de manera exclusiva a un solo proceso, nunca tendríamos bloqueos, pero esto es imposible de aplicar, en especial en relación a ciertos tipos de recursos, que en un momento dado no pueden ser compartidos (ej.: impresoras).

Se debe:

Evitar

la

asignación

de

un

recurso

cuando

no

sea

absolutamente necesario.

 

Intentar asegurarse de que los menos procesos posibles puedan pedir el recurso.

Prevención de la Condición “detenerse y esperar” o “espera por”

Si se puede evitar que los procesos que conservan recursos esperen más recursos, se pueden eliminar los bloqueos.

Una forma es exigir a todos los procesos que soliciten todos los recursos antes de iniciar su ejecución; si un proceso no puede disponer de todos los recursos, deberá esperar, pero sin retener recursos afectados.

Un problema es que muchos procesos no saben el número de recursos necesarios hasta iniciar su ejecución.

Otro problema es que puede significar desperdicio de recursos, dado que todos los recursos necesarios para un proceso están afectados al mismo desde su inicio hasta su finalización.

19

Otro criterio aplicable consiste en:

Exigir a un proceso que solicita un recurso que libere en forma temporal los demás recursos que mantiene en ese momento.

Hacer que el proceso intente luego recuperar todo al mismo tiempo.

Prevención de la Condición de “no apropiación”

Una de las estrategias de Havender requiere que cuando a un proceso que mantiene recursos le es negada una petición de recursos adicionales; deberá liberar sus recursos y si es necesario pedirlos de nuevo junto con los recursos adicionales.

La implementación de esta estrategia niega la condición de “no apropiación” y los recursos pueden ser retirados de los procesos que los retienen antes de la terminación de los procesos.

El problema consiste en que el retiro de ciertos recursos de un proceso puede significar:

La pérdida del trabajo efectuado hasta ese punto.

La necesidad de repetirlo luego.

Una

consecuencia

seria

es

la

posible

postergación

indefinida

de

un

proceso.

 
 

20

Prevención de la Condición de “espera circular”

Una forma es que un proceso solo está autorizado a utilizar un recurso en cada momento:

Si necesita otros recursos, debe liberar el primero.

Esto resulta inaceptable para muchos procesos.

Otra forma es la siguiente:

Todos los recursos se numeran globalmente.

Los procesos pueden solicitar los recursos en cualquier momento:

Las solicitudes se deben hacer según un cierto orden numérico (creciente) de recurso; debido a lo cual la gráfica de asignación de recursos no tendrá ciclos.

En cada instante uno de los recursos asignados tendrá el número más grande:

El proceso que lo posea no pedirá un recurso ya asignado.

El proceso terminará o solicitará recursos con números mayores , que estarán disponibles:

Al concluir liberará sus recursos.

Otro proceso tendrá el recurso con el número mayor y también podrá terminar.

Todos los procesos podrán terminar y no habrá bloqueo.

Una variante consiste en eliminar el requisito de adquisición de recursos en orden creciente:

Ningún proceso debe solicitar un recurso con número menor al que posee en el momento.

El problema es que en casos reales podría resultar imposible encontrar un orden que satisfaga a todos los procesos.

21

PREDICCIÓN DEL INTERBLOQUEO

Una forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevención, es la predicción del interbloqueo. En la prevención de interbloqueo, se obligaba a las solicitudes de recursos a impedir que sucediera, por lo menos, alguna de las cuatro condiciones de interbloqueo. Esto se hace indirectamente, impidiendo la aparición de una de las tres condiciones necesarias (exclusión mutua, retención y espera, no apropiación) o directamente, impidiendo la aparición de un circulo viciosos de espera. Se llega así a un uso ineficiente de los recursos y una ejecución ineficiente de los procesos. Con predicción del interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se realizan elecciones acertadas para asegurar que nunca se llega al punto de interbloqueo. La predicción, por lo tanto, permite más concurrencia que la prevención.

Con predicción del interbloqueo, se decide dinámicamente si la petición actual de asignación de un recurso podría, de concederse, llevar potencialmente a un interbloqueo. La predicción del interbloqueo necesita, por lo tanto, conocer las peticiones futuras de recursos.

Demanda indica las exigencias máximas de recursos para cada proceso, con una fila para cada uno. Es decir, Cij = demanda del recurso j por parte del proceso i. Esta información debe declararse por adelantado para que funcione la predicción de interbloqueo. De forma similar, Aij = asignación del recurso j al proceso i. Se puede ver que se cumplen las siguientes relaciones:

1. Para todo i, R i = D i + Σ A ki : todos los recursos están asignados o

disponibles.

22

2. Para todo k e i, C ki <= R i : ningún proceso puede demandar más

recursos que la cantidad total de recursos del sistema

Para todo k e i, A ki <= C ki : ningún proceso tiene asignados más

recursos de cualquier tipo que los que ha declarado necesitar.

Con estas tres cantidades, se puede definir una política de predicción del interbloqueo que rechace iniciar un nuevo proceso si sus exigencias de recursos pueden conducir a un interbloqueo. Un nuevo proceso P n+1

comenzará sólo si:

R i >= C (n+1)i + Σ C ki , para todo i

Es decir, un proceso comenzará sólo si puede servirse la demanda máxima de todos los procesos actuales más la del nuevo proceso. Esta estrategia es poco óptima, puesto que asume el caso peor: que todos los procesos expresen su demanda máxima a la vez.

Negativa de asignación de recursos

La estrategia de negar la asignación de recursos, denominada algoritmo del banquero, fue propuesta por primera vez por Dijkstra, que usó este nombre por la analogía de este problema con el de un banco cuando los clientes quieren obtener dinero prestado. Los clientes sería los procesos y el dinero a prestar, los recursos. Si se enuncia de esta manera, el banco tiene una reserva limitada de dinero para prestar y un conjunto de clientes con líneas de crédito. Un cliente puede elegir pedir dinero a cargo de la línea de crédito en un instante dado y no hay garantía de que el cliente realice ninguna reposición hasta después de sacar la cantidad máxima. El banquero puede rechazar un préstamo a un cliente si hay riesgo de que el banco no tenga fondos suficientes para hacer préstamos futuros que los clientes finalmente repondrán.

23

ALGORITMO DEL BANQUERO

Sea Solicitudi el vector de solicitudes para el proceso Pi. Pi efectúa una solicitud de recursos y el asignador de recursos toma las siguientes acciones:

1 Si Solicitudi Necesidadi, continuar con el paso 2. De lo contrario, devolver error, puesto que el proceso se ha excedido de su demanda máxima.

2 Si Solicitudi Disponible, continuar en el paso 3. De lo contrario, Pi deberá esperar, pues los recursos no están disponibles.

3 El sistema calcula el nuevo estado de asignación. Es decir,

Disponible := Disponible - Solicitudi Asignacióni := Asignacióni + Solicitudi Necesidadi := Necesidadi – Solicitudi

4 Analizar la seguridad del nuevo estado (algoritmo de seguridad). Si el

estado resultante es seguro, se confirma la transacción y los recursos son definitivamente asignados a Pi. Si el nuevo estado no es seguro, se restablece el estado anterior y Pi deberá esperar para obtener los recursos solicitados.

Cuando un recurso es liberado, el asignador de recursos actualiza la estructura de datos Disponible y reconsidera las peticiones pendientes, de ese tipo de recurso.

Para empezar se definen los conceptos de estado y de estado seguro. Considérese un sistema con un número fijo de procesos. Así pues, el estado estará formado por los dos vectores, Recursos y Disponible, y las dos matrices, Demanda y Asignación, definidas anteriormente. Un estado

24

seguro es un estado en el cual existe al menos una secuencia que no lleva al interbloqueo ( es decir, todos los procesos pueden ejecutarse hasta el final). Un estado inseguro es, naturalmente, un estado que no es seguro.

El algoritmo del banquero usa una tabla de recursos para saber cuántos recursos tiene de todo tipo. También requiere que los procesos informen del máximo de recursos que va a usar de cada tipo. Cuando un proceso pide un recurso, el algoritmo verifica si asignándole ese recurso todavía le quedan otros del mismo tipo para que alguno de los procesos en el sistema todavía se le pueda dar hasta su máximo. Si la respuesta es afirmativa, el sistema se dice que está en 'estado seguro' y se otorga el recurso. Si la respuesta es negativa, se dice que el sistema está en estado inseguro y se hace esperar a ese proceso.

Los algoritmos siguientes muestran una versión abstracta de la logica de predicción del interbloqueo. Con el estado del sistema definido por la estructura de datos estado, solicitud [*] es un vector que define los recursos pedidos por el proceso i. En primer lugar, se hace una comprobación para asegurar que la solicitud no excede la demanda inicial del proceso. Si la solicitud es válida, el paso siguiente es determinar si es posible satisfacer la solicitud, esto es, si hay suficientes recursos disponibles. Si no es posible, el proceso se suspende. Si es posible, el paso final es determinar si es seguro satisfacer la solicitud. Para hacer esto, se prueba a asignar los recursos al proceso i desde nuevo_estado. Después, se realiza un test d seguridad usando el algoritmo del banquero.

25

Estructura de datos globales

struct estado

{

int recursos [m];

int disponible [m];

int demada [n] [m];

int asignación [n] [m];

}

Algoritmo de asignación de recursos

if (asignación[i, ] + solicitud [*] > demanda [I, *])

{

 

<

error >;

/*-- solicitud total > demanda */

}

else if (solicitud [*] > disponible [*])

{

<

suspender proceso > ;

}

else

/*-- simular asignación */

{

 

<

definir nuevo_estado como:

asignación[i, ] = asignación[i, ] + solicitud [*]:

disponible [*] = disponible [*] – solicitud [*] >;

}

if (seguro (nuevo_estado))

{

< realizar asignación >;

26

}

else

{

< restaurar estado original >;

< suspender proceso >;

}

Algoritmo de comprobación de estado seguro (algoritmo del banquero)

booleano seguro (estado S)

{

int disponible_actual [m];

proceso resto [< número de procesos >];

disponible_actual = disponible;

resto = {todos los procesos};

posible = true;

while (posible)

{

encontrar un PK en resto tal que

demanda [k, *] – asignación [k, *] < = disponible_actual;

if (encontrado) /*-- simular ejecución de P */

{

disponible_actual = dispible_actual + asignación [k, *];

resto = resto – {PK};

}

else

posible = falso;

27

}

seguro (resto = = null);

}

La predicción del interbloqueo tiene la ventaja de que no es necesario expulsar y hacer retroceder procesos, como en la detección del interbloqueo, y es menos restrictiva que la prevención. Sin embargo, su uso supone una serie de restricciones como las siguientes:

- Se debe presentar la máxima demanda de recursos por anticipado.

- Los procesos a considerar deben ser independientes, es decir, que el orden en que se ejecuten no debe estar forzado por condiciones de sincronización.

- Debe haber un número fijo de recursos a repartir y un número fijo de procesos.

- Los procesos no pueden finalizar mientras retengan recursos.

RECUPERACIÓN DEL INTERBLOQUEO

Para romper el bloqueo de un sistema hay que anular una o más de las condiciones necesarias para el bloque.

Normalmente, varios procesos perderán algo o todo lo realizado hasta el momento.

Los principales factores que dificultan la recuperación del bloqueo son los siguientes:

Puede no estar claro si el sistema se ha bloqueado o no.

Muchos sistemas tienen limitaciones para suspender un proceso por tiempo indefinido y reanudarlo más tarde:

o Ej.: Los procesos de tiempo real, que deben funcionar continuamente, no son fáciles de suspender y reanudar.

Los procedimientos de suspensión / reanudación implican una sobrecarga considerable.

28

La sobrecarga de recuperación está en función de la magnitud del bloqueo (algunos, decenas o centenas de procesos involucrados).

Generalmente la recuperación suele realizarse:

Retirando forzosamente (cancelando) a un proceso.

Reclamando sus recursos.

Permitiendo que los procesos restantes puedan finalizar.

Los procesos pueden ser retirados (cancelados) de acuerdo a un orden de prioridades, existiendo las siguientes dificultades:

Pueden no existir las prioridades de los procesos bloqueados.

Las prioridades instantáneas (en un momento dado), pueden ser incorrectas o confusas debido a consideraciones especiales, por ej.: procesos de baja prioridad que tienen prioridad alta momentáneamente debido a un tiempo tope inminente.

La decisión óptima puede requerir un gran esfuerzo.

Algunas formas de recuperación ante bloqueos son:

Recuperación mediante la apropiación.

Recuperación mediante rollback.

Recuperación mediante la eliminación de procesos.

Recuperación Mediante la Apropiación

En ciertos casos podría ser posible tomar un recurso temporalmente de su poseedor y dárselo a otro proceso, por ej.:

29

Retirar una impresora de un proceso para dedicarla a otro proceso.

Retomar luego el primer proceso reasignándola al mismo.

La recuperación de recursos de esta forma depende en gran medida de la naturaleza del recurso.

La elección del proceso a suspender depende mucho:

De cuáles procesos poseen recursos que pueden ser tomados con facilidad.

De las posibilidades de recuperación luego de la apropiación.

Recuperación Mediante Rollback

En los S. O. donde es posible que ocurran bloqueos se puede hacer que los procesos sean verificados periódicamente:

Su estado se graba en un archivo de modo que pueda volver a iniciar más tarde.

El punto de verificación o de control contiene:

o

La imagen de la memoria.

o

El estado de los recursos, es decir, el detalle de los recursos asignados al proceso en ese instante.

Los puntos de verificación grabados durante un proceso se mantienen sin ser regrabados.

Al detectarse un bloqueo es fácil ver cuáles son los recursos necesarios.

Para la recuperación, un proceso que posee un recurso necesario regresa hasta cierto instante en el tiempo anterior a la adquisición:

Inicializa alguno de sus anteriores puntos de verificación.

El proceso regresa a un momento anterior en el que no poseía el recurso.

El recurso se asigna ahora a uno de los procesos bloqueados.

Si el proceso que volvió a iniciar intenta adquirir de nuevo el recurso, tendrá que esperar hasta que esté disponible.

30

Recuperación Mediante la Eliminación de Procesos

Es la forma más sencilla de romper un bloqueo.

Una posibilidad es eliminar un proceso del ciclo: si el bloqueo no se rompe, se puede intentar con otro proceso del ciclo, hasta romper dicho ciclo.

Otra posibilidad es eliminar un proceso que no esté en el ciclo, para poder liberar sus recursos: debe elegirse un proceso que posea recursos necesarios por algún proceso del ciclo.

Siempre que sea posible, es mejor eliminar un proceso que pueda volver a iniciar su ejecución sin efectos dañinos:

o

Es preferible eliminar un proceso de compilación que un proceso de actualización de una base de datos:

La compilación se puede repetir sin problemas. La actualización de una base de datos no siempre se puede repetir directamente.

MECANISMO PARA EVITAR EL INTERBLOQUEO

En este análisis se supone implícitamente que si un proceso solicita recursos, los solicita todos al mismo tiempo:

En la mayoría de los sistemas los recursos se solicitan uno a la vez.

El S. O. debe poder:

o

Decidir si el otorgamiento de un recurso es seguro o no.

o

Asignarlo solo en caso de que sea seguro.

El objetivo es evitar el bloqueo haciendo la elección correcta todo el tiempo, pero para evitar los bloqueos se requiere de cierta información de antemano.

Trayectorias de Recursos

Los principales algoritmos para evitar los bloqueos se basan en el concepto de estados seguros:

31

El ejemplo de modelo gráfico utilizado indica lo siguiente: • Es válido para dos procesos

El ejemplo de modelo gráfico utilizado indica lo siguiente:

Es válido para dos procesos y dos recursos.

El eje horizontal representa el número de instrucciones ejecutadas por el proceso “A”.

El eje vertical representa el número de instrucciones ejecutadas por el proceso “B”.

En “I1”; “A” solicita una impresora y en “I 2” necesita un plotter.

En “I 3” e “I 4” se liberan la impresora y el plotter.

El proceso “B” necesita el plotter desde “I5” hasta “I7” y la impresora desde “I6” hasta “I8”.

Cada punto del diagrama representa un estado conjunto de los dos procesos.

El estado inicial es “p”, sin que los procesos hayan ejecutado instrucción alguna.

Si el planificador del S. O. elige “A” se pasa a “q”, en donde “A” ha ejecutado instrucciones pero no “B”.

En “q” la trayectoria se vuelve vertical, ya que el planificador ha elegido ejecutar “B”.

32

Con un monoprocesador todas las trayectorias serán horizontales o verticales (no diagonales).

Cuando “A” cruza la línea “I1” en la trayectoria de “r” a “s”, solicita y se le otorga la impresora.

Cuando “B” alcanza el punto “t”, solicita el plotter.

La región delimitada por “I 1”, “I 3”, “I6” e “I 8” representa que ambos procesos poseen la impresora, pero esto es imposible y la regla de exclusión mutua impide la entrada a esta región.

La región delimitada por “I 2”, “I 4”, “I 5” e “I 7” representa que ambos procesos poseen el plotter, lo que es imposible.

Si el sistema ingresara a la región delimitada por “I 1”, “I 2”, “I 5” e “I 6” se bloqueará en la intersección de “I 2” e “I 6”:

o

Acá, “A” solicita el plotter y “B” la impresora, que ya están asignados.

o

Toda la región no es segura y no hay que entrar a ella:

En “t”, lo único seguro es ejecutar “A” hasta llegar a “I 4”. Luego se puede utilizar cualquier trayectoria hasta “u”.

En “t”, “B” solicita un recurso:

o

El S. O. debe decidir si lo otorga o no.

o

Si lo otorga, el sistema entrará a una región insegura y se bloqueará en algún momento.

o

Para evitar el bloqueo, hay que suspender a “B” hasta que “A” haya solicitado y liberado el plotter.

El Algoritmo del Banquero (de Dijkstra) Para Solo Un Recurso

Es un algoritmo de planificación que puede evitar los bloqueos

En la analogía:

Los clientes son los procesos, las unidades de crédito son los recursos del sistema y el banquero es el S. O.

33

El banquero sabe que no todos los clientes necesitaran su crédito máximo otorgado en forma inmediata, por ello reserva menos unidades (recursos) de las totales necesarias para dar servicio a los clientes.

Un estado inseguro no tiene que llevar a un bloqueo.

El algoritmo del banquero consiste en:

Estudiar cada solicitud al ocurrir ésta.

Ver si su otorgamiento conduce a un estado seguro:

o

En caso positivo, se otorga la solicitud.

o

En caso negativo, se la pospone.

Para ver si un estado es seguro:

o

Verifica si tiene los recursos suficientes para satisfacer a otro cliente:

En caso afirmativo, se supone que los préstamos se pagarán. Se verifica al siguiente cliente cercano al límite y así sucesivamente.

o

Si en cierto momento se vuelven a pagar todos los créditos, el

o

estado es seguro y la solicitud original debe ser aprobada.

El Algoritmo del Banquero (de Dijkstra) Para Varios Recursos

Acá también los procesos deben establecer sus necesidades totales de recursos antes de su ejecución y dada una matriz de recursos asignados, el S. O. debe poder calcular en cualquier momento la matriz de recursos necesarios.

34

Se dispone de: • “E”: vector de recursos existentes. • “P”: vector de recursos poseídos.

Se dispone de:

“E”: vector de recursos existentes.

“P”: vector de recursos poseídos.

“A”: vector de recursos disponibles.

El algoritmo para determinar si un estado es seguro es el siguiente:

1. Se busca un renglón “R” cuyas necesidades de recursos no satisfechas sean menores o iguales que “A”:

o Si no existe tal renglón, el sistema se bloqueará en algún momento y ningún proceso podrá concluirse.

2. Supongamos que el proceso del renglón elegido solicita todos los recursos que necesita y concluye:

o Se señala el proceso como concluido y se añaden sus recursos al vector “A”.

3. Se repiten los pasos 1 y 2:

o

Hasta que todos los procesos queden señalados como concluidos, en cuyo caso, el estado inicial era seguro, o

o

Hasta que ocurra un bloqueo, en cuyo caso, no lo era.

Asignación de Recursos por el Algoritmo del Banquero

35

Se permiten las condiciones de “exclusión mutua”, “espera por” y “no apropiatividad”.

Los procesos reclaman uso exclusivo de los recursos que requieren.

Los procesos mantienen los recursos mientras piden y esperan por otros recursos adicionales, pero no pueden apropiarse de un proceso que mantenga esos recursos.

Las peticiones son de un recurso a la vez.

El S. O. puede conceder o negar cada una de las peticiones; si se niega una petición:

El proceso retiene los recursos que ya tiene asignados.

Espera un tiempo finito hasta que le sea atendida la petición.

El S. O. concede peticiones que den como resultado solo estados seguros.

Dado que el sistema se mantiene siempre en estado seguro, todas las peticiones serán atendidas en un tiempo finito.

ESTADOS SEGUROS E INSEGURO

Un estado actual está conformado por “E”, “A”, “C” y “R”:

“E”: vector de recursos en existencia.

“A”: vector de recursos disponibles.

“C”: matriz de asignación actual.

“R”: matriz de solicitudes.

Un estado es seguro si:

No está bloqueado.

36

Existe una forma de satisfacer todas las solicitudes pendientes, mediante la ejecución de los procesos en cierto orden.

Ejemplo con un recurso para demostrar que el estado en (a) es seguro:

El estado es seguro ya que existe una sucesión de asignaciones que permiten terminar a todos los procesos; dicha sucesión de asignaciones es la siguiente:

procesos; dicha sucesión de asignaciones es la siguiente: Ejemplo con un recurso para mostrar un estado

Ejemplo con un recurso para mostrar un estado inseguro :

Ejemplo con un recurso para mostrar un estado inseguro : • No se puede garantizar que

No se puede garantizar que terminen los tres procesos.

Si el proceso “A” pide y se le otorga una unidad, puede producirse un bloqueo de tres vías si cada uno de los procesos necesita al menos otra unidad del recurso antes de liberar ninguna.

Un estado inseguro:

No implica la existencia, ni siquiera eventual, de bloqueo.

Sí implica que alguna secuencia infortunada de eventos dé como resultado un bloqueo.

37

La diferencia entre estado seguro e inseguro es que:

A partir de un estado seguro, el sistema puede garantizar la conclusión de todos los procesos.

A partir de un estado inseguro, no existe tal garantía.

Ejemplo de una transición de estado seguro a estado inseguro.

de una transición de estado seguro a estado inseguro . • Dado un estado actual seguro,

Dado un estado actual seguro, ello no implica que vayan a ser seguros todos los estados futuros.

38

VENTAJAS Y DESVENTAJAS DE LAS DIFERENTES ESTRATEGIAS

Estrategia

Ventajas

Desventajas

 

Funciona bien con procesos que realizan una sola ráfaga de actividad.

·

 

·

Ineficiencia.

No es necesaria la apropiación.

·

Retrasos en el inicio de los procesos.

·

·

Conveniente cuando se

aplica a recursos cuyo estado se puede salvar y restaurar fácilmente.

Apropia más habitualmente de lo necesario.

·

Prevención

· Sujeto a reinicios cíclicos.

Aplicación factible por medio de chequeos durante la compilación.

·

· No permite las solicitudes

Incrementales de recursos.

·

No hace falta procesamiento

·

Poco uso de la apropiación.

durante la ejecución, pues el

problema se resuelve durante el diseño del sistema.

Detección

Nunca retrasa el inicio de un proceso.

·

Pérdidas inherentes a la apropiación.

·

Facilita el manejo en línea.

   

-Deben conocerse las demandas futuras de recursos.

Predicción

No es necesaria la apropiación.

·

·

Los procesos pueden

 

bloquearse durante largos periodos.

39