M1L4

Interbloqueos y representación
gráfica
Introducción
Pensemos en los hilos como los nodos de un gráfico dirigido cuyos arcos representan la
relación "El hilo A está esperando por un recurso retenido por el hilo B". Si este gráfico
es cíclico, hay un interbloqueo o deadlock.
Este tipo de situaciones pueden ocurrir de manera frecuente, si los hilos no adquieren
los locks que necesiten en un orden global fijo.
Interbloqueos o deadlock
Supongamos que tenemos 2 hilos, A y B, que requieren cada uno de los lockA y lockB.
Si un hilo llama a lockA y otro llama a lockB, y sus acciones se intercalan como se
muestra en la figura 1, se interbloquearán.
Figura 1: Ejemplo de deadlock
Fuente: elaboración propia.
Veamos este caso de deadlock en lenguaje Java:
package interbloqueo;
public class Interbloqueo implements Runnable{
String lockA;
String lockB;
public Interbloqueo(String lockA, String lockB) {

this.lockA = lockA;
this.lockB = lockB;
}
@Override
public void run()
{
synchronized(lockA)
{
System.out.println(String.format("El hilo %s tiene %s, necesita %s",
Thread.currentThread().getName(), lockA, lockB));
synchronized (lockB)
{
}
}
}
}
public class Ejecutar {
public static void main(String[] args) {
String lockA = "lockA";
String lockB = "lockB";
new Thread(new Interbloqueo(lockA,lockB),"A").start();
new Thread(new Interbloqueo(lockB,lockA),"B").start();
}
}
Como salida obtenemos
El hilo B tiene lockB, necesita lockA
El hilo A tiene lockA, necesita lockB
El deadlock en la clase Interbloqueo() se produjo porque los dos hilos

intentaron adquirir los mismos locks en un orden diferente. Si solicitaran los
locks en el mismo orden, no habría dependencia de bloqueo cíclico y, por lo
tanto, no habría interbloqueo.
Los hilos o procesos usan los recursos de acuerdo con el siguiente protocolo:
1. Petición. El hilo tendrá que solicitar el uso del recurso a su gestor. En función del
estado del recurso, el gestor se lo podrá otorgar o no. La mayoría de los recursos
exigen un uso en exclusión mutua: solo un proceso o hilo puede utilizarlos en cada
momento y mientras no finalice su actividad, todos los demás solicitantes tendrán
que esperar.
2. Uso. Una vez el gestor ha asignado el recurso a cierto hilo o proceso, este podrá
utilizarlo. Como ya se ha dicho en el punto anterior, esa instancia asignada solo
será utilizada por un hilo o proceso en cada momento.
3. Liberación. Cuando finalice el uso del recurso, el hilo o proceso indicará al gestor
que ya no lo necesita y así el gestor podrá asignarlo a otro solicitante (Muñoz
Escoí, Argente Villaplana, Espinosa Minguet, Galdámez Saiz, García-Fornes, De
Juan Marín, Sendra Roig, 2012).
Como resultado de este protocolo, un hilo A espera a otro hilo B cuando A solicita un
recurso que ahora mismo esté asignado a B. Mientras B no libere dicho recurso, A
permanecerá esperando tal liberación. Cuando ciertos conjuntos de hilos no puedan
progresar debido a que haya un ciclo de esperas entre ellos, se dará un interbloqueo
(Muñoz Escoí et al., 2012).
¿Y entonces en qué caso se dará el deadlock o interbloqueo?

Para esta pregunta, la respuesta está en las condiciones de Coffman, que formulan lo
siguiente:
1. mientras exista exclusión mutua, es decir, cuando una instancia de un recurso este
asignada a un proceso, otros procesos no podrán obtenerla;
2. retención y espera: como los recursos se solicitan a medida que se necesitan, un
proceso podrá tener algún recurso asignado y solicitar otro que en ese momento
no esté disponible, obligándolo a suspenderse;
3. no exclusión: cuando un recurso ya esté asignado solo podrá liberarlo su dueño;
4. espera circular: en el grupo de procesos interbloqueados, cada uno está
esperando un recurso asignado a otro proceso del grupo. Con ello, se cierra un
ciclo de esperas y ninguno de los procesos puede proseguir con su ejecución.
Si estas cuatro condiciones se cumplen simultáneamente en un sistema, existirá riesgo

de interbloqueo. Sin embargo, al no ser condiciones suficientes, no existe la garantía de
que tal interbloqueo exista.
Con la utilización de un grafo de asignación de recursos (GAR), que muestra las

peticiones de recursos por parte de los procesos (o hilos) y las asignaciones realizadas,
se puede detectar si en un momento determinado existe o puede existir un interbloqueo.
En el ejemplo de la figura 2, tenemos la representación del interbloqueo visto más arriba:

dos procesos (A y B) y dos recursos (lockA y lockB).
Figura 2: Grafo de asignaciones de recursos
Fuente: elaboración propia.

Los procesos son graficados como círculos, y los recursos, como rectángulos. Aquellos
nodos que modelen a los recursos tendrán tantos puntos internos como instancias
tengan tales recursos, en nuestro caso uno cada uno. Luego tenemos dos tipos de
aristas, las aristas de petición y las de asignación.
La arista de petición es la que parte de un proceso Pi y llega a un recurso Rj.

Representa la solicitud de una instancia de Rj por parte del proceso Pi e indica que
dicha solicitud no ha podido ser atendida de manera inmediata (por no haber suficientes
instancias libres), quedando el proceso Pi bloqueado al realizar tal petición. En nuestro
caso de A a lockB (necesita lockB) y B a lockA (necesita lockA). (Muñoz Escoí et al.,
2012)
La arista de asignación es la que parte de una instancia concreta del recurso Rj y llega a
un proceso Pi. Indica que esa instancia del recurso Rj se ha podido asignar al proceso Pi
y este todavía la utiliza. Cuando finalice su uso, el proceso liberará esa instancia y la
arista de asignación correspondiente se eliminará del grafo. En nuestro caso, el hilo B
tiene lockB, el hilo A tiene lockA.
Existen las siguientes cuatro estrategias posibles para afrontar las situaciones de
interbloqueo en un sistema: prevención, diseñando el sistema de modo que se rompa
alguna de las condiciones de Coffman, asegurando así que el sistema nunca entrará en
un estado de interbloqueo; evitación, monitorizando las peticiones de recursos y
evaluando si resulta seguro asignar las instancias solicitadas; detección y
recuperación, permitiendo que el sistema entre en un estado de interbloqueo, pero
detectándolo y luego recuperándose de él, terminando alguno de los procesos
interbloqueados o desalojando recursos que tengan ocupados; e ignorar el problema,
actuando como si los interbloqueos nunca fueran a producirse en el sistema. (Muñoz
Escoí et al., 2012)
Referencias
Muñoz Escoí, F.D.; Argente Villaplana, E.; Espinosa Minguet, A.; Galdámez Saiz, P.;
García-Fornes , A.; De Juan Marín, R.; Sendra Roig, J. (2012). Concurrencia y
sistemas distribuidos. Valencia, España: Universitat Politècnica.

M1L4

Cargado por

Copyright:

Formatos disponibles

M1L4

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

M1L4

Cargado por

Copyright:

Formatos disponibles

Interbloqueos y representación

Fuente: elaboración propia.

Veamos este caso de deadlock en lenguaje Java:

public Interbloqueo(String lockA, String lockB) {

El deadlock en la clase Interbloqueo() se produjo porque los dos hilos

¿Y entonces en qué caso se dará el deadlock o interbloqueo?

Si estas cuatro condiciones se cumplen simultáneamente en un sistema, existirá riesgo

Con la utilización de un grafo de asignación de recursos (GAR), que muestra las

En el ejemplo de la figura 2, tenemos la representación del interbloqueo visto más arriba:

Fuente: elaboración propia.

La arista de petición es la que parte de un proceso Pi y llega a un recurso Rj.

También podría gustarte