Interbloqueo (Sistema Operativo)
En sistemas operativos, el bloqueo mutuo (también conocido como
interbloqueo, traba mortal, deadlock, abrazo mortal) es el bloqueo
permanente de un conjunto de procesos o hilos de ejecución en un sistema
concurrente que compiten por recursos del sistema o bien se comunican
entre ellos. A diferencia de otros problemas de concurrencia de procesos,
no existe una solución general para los interbloqueos.
Todos los interbloqueos surgen de necesidades que no pueden ser
satisfechas, por parte de dos o más procesos. En la vida real, un ejemplo
puede ser el de dos niños que intentan jugar al arco y flecha, uno toma el
arco, el otro la flecha. Ninguno puede jugar hasta que alguno libere lo que
tomó.
En el siguiente ejemplo, dos procesos compiten por dos recursos que
necesitan para funcionar, que sólo pueden ser utilizados por un proceso a la
vez. El primer proceso obtiene el permiso de utilizar uno de los recursos
(adquiere el locksobre ese recurso). El segundo proceso toma el lock del
otro recurso, y luego intenta utilizar el recurso ya utilizado por el primer
proceso, por lo tanto queda en espera. Cuando el primer proceso a su vez
intenta utilizar el otro recurso, se produce un interbloqueo, donde los dos
procesos esperan la liberación del recurso que utiliza el otro proceso.
Administración de procesos
Necesidad: La sincronización de procesos creados por diferentes equipos de
programadores, está a cargo del sistema operativo
Definiciones
Interbloqueo:
Se dice que dos o más procesos están bloqueados, cuando están
suspendidos en espera de un evento que sólo puede ser activado por uno de
los procesos bloqueados, y por lo tanto dicho evento nunca sucederá
Postergación indefinida o Inanición (Starving)
Se dice que uno o más procesos están en postergación indefinida cuando la
política de planificación del sistema permite que un proceso quede en
espera de un evento por un tiempo indefinido. Esto puede suceder, por
ejemplo, cuando la asignación de recursos se realiza por prioridad. De este
modo un proceso de baja prioridad estará suspendido mientras existan otros
procesos de mayor prioridad.
Envejecimiento: aumentar la prioridad de los procesos conforme pasa el
tiempo
Clasificación de recursos
Para el estudio del interbloqueo, los recursos se pueden clasificar en:
Compartido/exclusivos: Se dice que un recursos es compartido si
puede ser utilizado por más de un proceso al mismo tiempo. Son
exclusivos los que pueden ser utilizados sólo por un proceso a la vez
Apropiativos/inapropiativos: Son apropiativos los recursos asignados
a un proceso, que pueden ser desasignados del proceso, por al
sistema para asignarlos a otro proceso.
Los recursos involucrados en los interbloqueos son los exclusivos e
inapropiativos
Condiciones necesarias para el interbloqueo
Coffman, Elphuck y Shoshani, establecieron cuatro condiciones, necesarias
y suficientes, para que se dé un interbloqueo:
Exclusión mutua
Si dos procesos solicitan un recurso exclusivo, uno de los dos quedará
suspendido hasta que el favorecido libere el recurso.
Contención o retención y espera
Si un proceso necesita más de un recurso para realizar su trabajo,
conservará en su poder los recursos exclusivos ya asignados, mientras
espera por otro recurso adicional.
Inapropiatividad
Los recursos asignados a un proceso, sólo pueden ser liberados por el
proceso mismo y no pueden ser desasignados por el sistema, cuando otro
proceso los necesite.
Espera circular
Dependencia: Si un proceso P1 está suspendido en espera de un recurso
exclusivo que está asignado a otro proceso P2, entonces decimos que P1
depende de P2 (P1 <= P2).
Espera circular: Existe una cadena circular de procesos en espera de un
recurso, si existe una cadena de dependencias entre procesos de la forma
P1 <= P2 <= P3 <= ... <= Pn <= P1
Ejemplos:
Asignación de recursos sin ciclos
Asignación de recursos con espera circular e interbloqueados
Formas de enfrentar los interbloqueos
Existen varias políticas y estrategias que el sistema operativo puede tomas,
para tratar con los interbloqueos:
Indiferencia:Problema del usuario y del programador, lograr que no se dé el
interbloqueo.
Prevención:Consisten en condicionar el sistema con una serie de
restricciones a los programadores, para que no se den al menos una de las
condiciones del interbloqueo, por lo que éste nunca sucederá.
Evitación o predicción: Esta estrategia consiste en dejar que las condiciones
para el interbloqueo se puedan dar, pero en el momento de asignar
recursos, y se detecte que puede ocurrir un interbloqueo, deniega la
asignación del recurso que puede desencadenar el interbloqueo.
Detección y recuperación: En esta política, el sistema deja que suceda el
interbloqueo, pero se implementan procesos encargados de revisar el
estado de asignación de los procesos, para detectar los interbloqueo. Una
vez detectado, se pueden implementar políticas de recuperación de
interbloqueo, que básicamente consisten en matar procesos.
Indiferencia (algoritmo del avestruz)
Simple y eficiente, dado que el sistema operativo no gasta procesador ni
recursos en el manejo del interbloqueo. Usualmente es la política preferida
en los sistemas actuales
El costo esperado de un interbloqueo suele ser muy bajo
o Costo esperado = Probabilidad (desastre) * Costo (desastre)
Sólo se deben proporcionar herramientas para revisar el estado de los
procesos
complica el trabajo del operador
Prevención (Estrategias de Havender/Prevención estática)
Se pueden adoptar ¿4? posibles estrategias de prevención del interbloqueo,
una para cada condición. Ya que para se dé un interbloqueo son necesarias
las cuatro, con negar una de ellas, se niega la posibilidad del interbloqueo:
Negación de la exclusividad
Sólo se aplica a recursos compartidos, es muy difícil poder aplicarlo a todos
los recursos, dado que hay recursos que son inherentemente de uso no
compartido.
Uso de spoolers: dar un API concurrente (compartido) a los procesos para
accesar recursos. La estrategia básica es que un servicio del sistema
(daemon) proporciona un API, y ese servicio es el único que accesa el
recurso compartido, exclusivo. Ej: una impresa es un recurso exclusivo e
inapropiativo, pero con el uso de un spooler se convierte en un recurso
compartido.
Test & Get: un API especial que permite revisar primero si el recurso está
disponible, y pedirlo, o retornar un código de error que indica que no está
disponible. Requiere que los procesos hagan uso de este API.
Negación de la contención
Estrategia 1: El proceso pide al sistema TODOS los recursos a necesitar
antes de iniciar su proceso (todo o nada). No siempre se sabe cuántos
recursos se utilizarán.
Estrategia 2: También puede establecerse que un procesos puede pedir
recursos cuando no tiene recursos asignados
No siempre se conoce la cantidad de recursos que se necesitará, por lo que
lo que el operador debe configurar, por prueba y error, lograr que los
procesos funcionen adecuadamente
Obliga a optimizar los programas por medio de división. El programador de
modularizar extremadamente bien los procesos para utilizar los recursos
por fases, de forma que para cada fase, se piden los recursos y se liberan,
antes de la siguiente fase
La utilización de recursos resulta muy pobre
Puede resultar una postergación indefinida de un proceso que requiera
muchos recursos
Negación de la inapropiatividad
Si un proceso que tiene recursos asignados, pide un nuevo recurso que no
está disponible, deberá liberar los recursos asignados y pedirlos
posteriormente.
Sólo se aplica a recursos apropiativos y recursos que se pueden almacenar
su estado para reasignarlo, o que puedan hacerles rollback
puede llevar a que la ejecución de un proceso se prolongue indefinidamente,
debido a que nadie puede garantizar que termine en un tiempo determinado.
Pobre utilización del tiempo de procesamiento
Negación de la espera circular
Se impone un orden a los recursos
Cada proceso sólo puede pedir los recursos en orden ascendente (o
descendente)
Tiempo\requerimientos P1 P2 P3
t1 R1 (ok)
t2 R2 (ok)
t3 R3 (ok)
t4 R2 (*)
t5 R3 (*)
t6 R1 (*)
P1 => P2 => P3 => P1
Tiempo\requerimientos P1 P2 P3
t1 R1 (ok)
t2 R2 (ok)
t3 R1 (*)
t4 R2 (*)
t5 R3 (ok)
ti FINALIZA
ti DESPIERTA
Tj FINALIZA DESPIERTA
Tj+1 R3 (ok)
Tn FINALIZA
DEMOSTRACIÓN:
P0 => P1 => P2 => … => Pn => P0
Para que haya una dependencia de Pi A Pj, significa que Pi tiene asignados
recursos <= k, y está pidiendo un Rk+1, el cual está asignado a Pj, lo que
significa que Pj tiene asignados recursos >= k+1, por lo tanto Pn ¡=> P0
En general las técnicas de prevención, aunque logran su objetivo de eliminar
los interbloqueos, provocan una pobre utilización de los recursos,
incluyendo el procesador. También el algunos casos, provocan postergación
indefinida.
Evitación o Predicción ( Estrategias de Dijkstra, Habermann)
Con la evitación no se tienen reglas estáticas a los procesos, sino que el
sistema operativo analiza cada petición de recursos y determina si el
sistema quedará en un estado estable o inestable, en este último caso, se
deniega la petición, posponiéndola temporalmente.
Conceptos
La evitación se basa en los siguientes conceptos:
Estado de asignación de recursos:Número de recursos asignados,
disponibles y máximo de recursos posibles por proceso.
Secuencia segura:Secuencia de finalización de procesos, tal que todos los
procesos puedan finalizar exitosamente, iniciando en un determinado estado
de asignación de recursos
Estado seguro de asignación de recursos:Estado de asignación de recursos,
donde existe al menos una secuencia segura.
Estado inseguro de asignación de recursos: No existe ninguna secuencia
segura. Obsérvese, que aunque un estado inseguro no implica que exista
interbloqueo, talvez una secuencia determinada de eventos lleve a uno.
Algoritmo del banquero (Dijkstra, Habermann)
En este algoritmo, de evitación en general procede así:
Necesita que cada proceso declare el máximo número de recursos a utilizar
En cada requerimiento, determina si el asignar los recursos pedidos deja
un estado inseguro de asignación de recursos, entonces se pospone el
requerimiento. De lo contrario se asignan los recursos solicitados.
Procedimiento de asignación
Cuando un proceso solicita recursos, el sistema operativo procede así:
1. Determinar si hay disponibles
2. Determinar que no exceda su máximo declarado
3. Determinar que, si se concede la petición, el sistema quede en estado
seguro
Si no se cumple cualquiera de estas condiciones, el proceso queda
suspendido hasta que exista una liberación de recursos.
Estructuras de datos:
sea m el número de tipos de recursos y n el número de procesos
int disponible [m] ; unidades de R j disponibles
int max[n][m]; máximo número de requerimientos del proceso Pi del
recurso Rj
int asignado [n][m]; asignación actual del proceso P i del recurso Rj
int necesario [n][m]; necesario [i][j] = max [i][j] - asignados[i][j]
int requerimiento[m]; vector de requerimiento de cada petición de
recursos//
Relación <= entre vectores
si x in N m , y in N m : x <= y ssi para todo i = 0,...,m-1 : x[i] <= y[i]
Por ejemplo:
<1,1,1> <= <2,5,7>
<1,1,1> NO <= <2,0,7>
Algoritmo
void requerimiento_de_recursos (int requerimiento[], idProceso i) {
if (requerimiento >= necesario[i] )
error () ; máximo de recursos estimados agotados
i f (requerimiento >= disponible)
suspender () ; recursos no disponibles
disponible -= requerimiento;
asignado [i] += requerimiento;
necesario[i] -= requerimiento;
if (! estado_seguro ()) {
regresamos al estado anterior
disponible += requerimiento;
asignado[i] -= requerimiento;
necesario[i] += requerimiento;
suspender () ;
}
}
int estado_seguro() {
int disp_temp = disponible;
bool terminado[n] = (FALSE,...,FALSE);
int i;
encontrar un p[i] tal que terminado[i] = FALSE y necesario[i] <= disponible
while (terminado!=(TRUE,...TRUE)){
for (i=0; (i < n && terminado[i]) || necesario[i] > disp_temp); i++) {
if (i == n-1) {
return FALSE;
}else
if (!terminado[i]){
disp_temp += asignados[i] ;
terminado[i] = TRUE;
} if
} for
} while
return TRUE ;
}estado_seguro
Ejemplo
proceso\recurso R1 (7) R2(7) R3(7)
Maximos P1 5 3 1
P2 3 2 3
P3 2 3 1
P4 5 0 3
Asignados P1 3 3 1
P2 2 2 2
P3 0 1 1
P4 0 0 1
Necesarios P1 2 0 0
P2 1 0 1
P3 2 2 0
P4 5 0 2
Disponibles 2 1 2
Sobre este estado de asignación de recursos (qué es estable ¿?)
supongamos las siguiente peticiones de recursos:
P2[1,0,1]:El sistema queda en un estado seguro
P3[2,0,0]:El sistema queda en un estado inseguro
Desventajas
necesita el conocimiento del máximo por recurso que usará cada proceso
implica un retardo en cada asignación de recursos, lo que puede degradar el
sistema si se manejan muchos recursos y/o procesos
Se requiere una garantía de devolución: c/proceso liberará los recursos
asignados. (suponga que después de hacer la primera asignación de
recursos, el proceso P2 no termina, entonces ninguno de los procesos
podría terminar, sin necesidad de que haya interbloqueo.
Detección y recuperación
El sistema no impone ninguna clase de reglas para prevenir o evitar el
interbloqueo
Se puede tener un proceso de fondo o de activación manual que analice las
estructuras del sistema operativo y determine si existe o no un
interbloqueo.
Una vez detectado el interbloqueo se procede a la recuperación, que puede
ser automática o manual. Básicamente consiste en matar un proceso
Podría utilizar si no es muy costoso que haya un interbloqueo (el costo es
menor que el costo de implementar una de las otras políticas de
interbloqueo.
Normalmente sería utilizado como herramienta de diagnóstico y
recuperación
Detección por reducción de grafos de asignación
Detección por ciclos de espera
La técnica más sencilla para detectar un interbloqueo es deducir un grafo
dirigido de dependencias entre proceso por medio de las colas de espera en
cada recurso y determinar si existen un ciclo en dicho proceso.
Por ejemplo, en la siguiente gráfica, al lado izquierdo, se tiene un grafo del
estado actual de asignación de recursos y a la derecha vemos el grafo de
espera entre procesos. Como se puede apreciar, existe un ciclo en en grafo
de espera, por lo tanto existe un interbloqueo.
Condiciones necesarias para la detección
1. Conocer los procesos: acceso al PCB
2. Conocer los recursos: acceso a la tabla de recursos del sistema
3. Conocer la asignación: debemos poder saber qué recursos está asignado
a cada proceso
4. Conocer la espera: debemos poder saber en que recursos está esperando
(suspendido) un proceso
Recuperación
Una vez que se detecta un interbloqueo, corresponde la decisión sobre la
recuperación del sistema sobre ese interbloqueo, que básicamente se trata
de matar un proceso y recuperar sus recursos.
Esta recuperación puede ser manual o automática. La recuperación
automática es un tema difícil, ya que no se pueden establecer, fácilmente,
condiciones determinísticas para saber cuál es el proceso más adecuado de
eliminar. Existen algunas posibilidades:
El proceso con más recursos: se libera la mayor cantidad cantidad de
recursos, lo que permite continuar a la mayor cantidad de procesos. Se
deshace el "nudo" principal. Sin embargo tiene la desventaja que
normalmente será el proceso más importante, lo que implica el mayor daño,
o el mayor tiempo de repetición.
El proceso con menos recursos: se busca el menor daño, pero puede ser
que pocos procesos puedan continuar.
El proceso que esté involucrado en más ciclos o interbloqueos: se deshace
el mayor número de interbloqueos.
Sin embargo, hay que tomar en cuenta un criterio subjetivo: la
importancia del proceso, lo cual no está dado ni por la cantidad de recursos
que tiene asignados el proceso ni el número de interbloqueos en que está
involucrado. Lo cuál hace de la recuperación manual, una forma muy
recomendable, siempre y cuando se cuente con un operador entrenado en el
funcionamiento de los procesos del usuario.
Herramientas para el interbloqueo en los sistemas operativos existentes
SOLARIS
Utiliza la herramienta CAT (Crash Analysis Tool), que es parte del entorno
del sistema, y ayuda a analizar los archivos centrales del sistema. Esta
herramienta consiste en analizar la salida del desplome o error que se dio.
Esta herramienta genera archivos de salida en los cuales se describen las
causas que provocaron este estado en el sistema.
LINUX
Utiliza las siguientes herramientas:
GDB: Es una herramienta de rastreo y debugeo del kernel, con la
información obtenida en un error en el sistema.
INGO: Es un “perro guardián” que sirve para detectar y reportar los
interbloqueos.
SYSREQ: Permite observar las tareas, procesos y registros dentro del
kernel en caso de fallo.
KDB: Es un debugeador del kernel en línea de comando que sirve para
inspeccionar el estado de los procesos.
WINDOWS
Utiliza las siguientes herramientas:
WINDBG:
DBGMON:
I386KD: Es utilizado para cargar el archivo MEMORY.DMP, el que fue
generado por una computadora con WINDOWS NT. Este archivo contiene
información que puede ser observada para verificar la integridad del
sistema.
KD:
En general, la mayoría de herramientas sirven para observar el estado del
sistema, ya sea por el kernel o por archivos generados conteniendo la
información, y así poder saber el estado del sistema y que situaciones,
procesos y recursos se encuentran involucrados en llevar al sistema a su
estado actual.
Verifier.exe:a partir de WinXp, detecta interbloqueos en drivers
En Windows® XP La detección se presentó por medio del control orientado
a excepciones, que permite interceptar la cadena de control de excepciones
con propósitos de registro y diagnóstico. En Windows Vista™ Windows
Vista tiene una nueva API muy interesante denominada Cruce encadenado
con esperas (WCT). API Cruce permite determinar cuándo y por qué se
produce interbloqueo en un proceso. WCT notifica exactamente en qué
objeto de sincronización se encuentra el interbloqueo. Pero esta sólo
notifica un conjunto limitado de primitivas de sincronización. Aun con esta
limitante, resulta una API muy útil y que deseará tener en su kit de
herramientas de depuración. API de WCT Uso y sus limitaciones Uso
examina si un subproceso se encuentra en espera en una llamada de
bloqueo. Si el subproceso se encuentra en una llamada de bloqueo, busca el
objeto que el subproceso bloquea y determina, si es apropiado, el nombre
del objeto y qué subprocesos o procesos poseen ese objeto. Por ejemplo, si
el subproceso A espera que el proceso B complete la ejecución y el proceso
B invoca SendMessage para el proceso A, existe un interbloqueo que WCT
puede detectar y notificar. Limitaciones El único problema que observo con
la API de WCT es que no notifica interbloqueos cuando se usa
WaitForMultipleObjects, lo que reduce su utilidad en muchas aplicaciones.
Por ejemplo, la sincronización .NET usa WaitForMultipleObjects para toda la
coordinación de sincronizaciones. Aunque WCT no notificará que se produjo
un interbloqueo en el subproceso, notificará que el subproceso está
bloqueado. Lla API de WCT puede notificar los periodos de espera, por lo
que se puede decidir manualmente si se produjo interbloqueo en un
subproceso específico, a través de la inspección y comparación con una
herramienta como LockWatcher (parte de la descarga de código de este
artículo). WCT es una API típica de Win32®, lo cual significa que tiene que
obtener un identificador opaco, pasar ese identificador al método que
registra los datos y llamar a un formulario de CloseHandle cuando finalice.
La documentación del SDK de la plataforma muestra todo lo que se necesita
para inicializar y usar la API de WCT. En la inicialización, siempre deberá
llamar a la función RegisterWaitChainCOMCallback para registrar las
funciones COM CoGetCallState y CoGetActivationState para que WCT pueda
notificar al propietario COM. Dado que estas funciones no están
documentadas, necesitará obtenerlas de ole32.dll a través de
GetProcAddress. Para inicializar WCT, se debe usar la funcion
OpenThreadWaitChainSession exportada de advapi32.dll:
Top Related