2.4.3.3 Recuperacion Interbloqueo DeadLock

De acuerdo a Silbertschatz C. (1999), cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el operador se ocupe de él manualmente. La otra posibilidad es dejar que el sistema se recupere automáticamente del interbloqueo. Dentro de esta recuperación automática tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o más procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o más de los procesos bloqueados.

Silbertschatz C. (1999) apunta que la recuperación se suele realizar eliminando un proceso y quitándole sus recursos. El proceso eliminado se pierde, pero gracias a esto ahora es posible terminar. Algunas veces es necesario, eliminar varios procesos hasta que se hayan liberado los recursos necesarios para que terminen los procesos restantes.

Milenkovic, M. (1994). Sistemas operativos. Concepto y diseño (2a ed.) (pp. 191-195) México: Mc Graw Hill

2.4.3.2 Deteccion Interbloqueo DeadLock

Según Silbertschatz C. (1999), la detección del interbloqueo es el proceso de determinar si realmente existe un interbloqueo e identificar los procesos y recursos implicados en él. Una posibilidad detectar un interbloqueo es monitorear cada cierto tiempo el estado de los recursos. Cada vez que se solicita o se devuelve un recurso, se actualiza el estado de los recursos y se hace una verificación para observar si existe algún ciclo.

Algoritmo de detección del interbloqueo

Silbertschatz C. (1999) detalla que una comprobación para interbloqueo puede hacerse con igual o menor frecuencia que cada solicitud de recursos, dependiendo de qué tan probable es que ocurra un interbloqueo. Comprobar cada solicitud de recursos tiene dos ventajas: Conduce a la detección temprana y el algoritmo es simple, de manera relativa porque se basa en cambios crecientes al estado del sistema. Además, las comprobaciones frecuentes consumen un tiempo considerable de procesador.

Milenkovic, M. (1994). Sistemas operativos. Concepto y diseño (2a ed.) (pp. 187-191) México: Mc Graw Hill

2.4.3.1 Prevencion Interbloqueo DeadLock

De acuerdo Milenkovic, M. (1994), la estrategia básica de la prevención del interbloqueo consiste, a grandes rasgos, en diseñar su sistema de manera que esté excluida, a priori, la posibilidad de interbloqueo.

Milenkovic, M. (1994). menciona 2 tipos de métodos para prevenir el interbloqueo Los métodos indirectos que consisten en impedir la aparición de alguna de las tres condiciones necesarias para que se de el interbloqueo.

• Los métodos directos que consisten en evitar la aparición del círculo vicioso de espera.
  

Milenkovic, M. (1994) define la Exclusión mutua cuando: ningún recurso se puede asignar de forma exclusiva, no se producirá interbloqueo. Sin embargo, existen recursos para los que no es posible negar la condición de exclusión mutua. No obstante, es posible eliminar esta condición en algunos procesos.

Según Milenkovic, M. (1994), la retención y espera se orgina puede prevenirse exigiendo que todos los procesos soliciten todos los recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los recursos puedan concederse simultáneamente

Milenkovic, M. (1994) escribe que la condición de no apropiación puede prevenirse de varias formas. Primero, si a un proceso que retiene ciertos recursos se le deniega una nueva solicitud, dicho proceso deberá liberar sus recursos anteriores y solicitarlos de nuevo, cuando sea necesario, junto con el recurso adicional. Por otra parte, si un proceso solicita un recurso que actualmente está retenido por otro proceso, el sistema operativo debe expulsar al segundo proceso y exigirle que libere sus recursos.

Milenkovic, M. (1994). Sistemas operativos. Concepto y diseño (2a ed.) (pp. 184-185) México: Mc Graw Hill

2.4.3 Interbloqueo DeadLock

De acuerdo al concepto de Milenkovic, M. (1994), un interbloqueo se produce cuando dos o más tareas se bloquean entre sí permanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas intentan bloquear.

Milenkovic, M. (1994), define el estancamiento como: "Un conjunto de procesos se estancan si cada proceso del conjunto está esperando un evento que solo otro proceso del conjunto puede provocar". Puesto que todos los procesos están en espera, ninguno de ellos podrá ocasionar nuca ninguno de los eventos que podrían desbloquear a algunos de los otros miembros del conjunto y todos los procesos seguirán esperando indefinidamente.

Milenkovic, M. (1994). Sistemas operativos. Concepto y diseño (2a ed.) (pp. 180-183) México: Mc Graw Hill

2.4.2.2 Mecanismo de Monitores

De acuerdo a Tanenbaum A. (1998), monitor es un proceso que se encarga de verificar el funcionamiento de algún recurso garantizando la exclusión mutua) (mutex). En un monitor los procesos se bloquean y desbloquean.

Tanenbaum, A. (1998). Sistemas operativos. Diseño e Implementación (1a ed.) (pp.67-70)
México: Pretince-Hall

2.4.2.1 Mecanismo de Semáforos

En 1965, E.W. Dijkstra sugirió el uso de una variable entera para contar el número de despertares almacenados para su uso posterior.

En su propuesta se presentó un nuevo tipo de variable, llamada Semáforo. Un semáforo puede tener el valor 0, lo que indica que no existen despertares almacenados; o bien algún valor positivo si están pendientes uno o más despertares.

Dijkstra, propuso dos operaciones, DOWN y UP (generalizaciones de SLEEP y WAKEUP, respectivamente). La operación Down verifica si el valor de un semáforo es mayor que 0. En este caso, decrementa el valor (es decir, utiliza un despertar almacenado) y continúa. Si el valor es cero, el proceso se va a dormir. La verificación y modificación del valor, así como la posibilidad de irse a dormir se realiza en conjunto, como una sola e indivisible acción atómica. Se garantiza que al iniciar una operación con un semáforo, ningún otro proceso puede tener acceso a semáforo hasta que la operación termine o se bloquee. Esta atomicidad es absolutamente esencial para resolver los problemas de sincronización y evitar condiciones de competencia.

2.4.2 Sincronización de Procesos en SO

Milenkovic, M. (1994) menciona que en muchos casos, los procesos se reúnen para realizar tareas en conjunto, a este tipo de relación se le llama procesos cooperativos. Para lograr la comunicación, los procesos deben sincronizarse, de no ser así pueden ocurrir problemas no deseados. La sincronización es la coordinación y cooperación de un conjunto de procesos para asegurar la comparación de recursos de cómputo. La sincronización entre procesos también permite intercambiar señales de tiempo (ARRANQUE/PARADA) entre procesos cooperantes para garantizar las relaciones específicas de precedencia impuestas por el problema que se resuelve.

Milenkovic, M. (1994) sugiere que para que los procesos puedan sincronizarse es necesario disponer de servicios que permitan bloquear o suspender bajo determinadas circunstancias la ejecución de un proceso. Los principales mecanismos de sincronización que ofrecen los sistemas operativos son:

• Señales

• Tuberías

• Semáforos

• Mutex y variables condicionales

• Paso de mensajes

Milenkovic, M. (1994). Sistemas operativos. Concepto y diseño (2a ed.) (pp. 39-40) México: Mc Graw Hill