Bloque 1Bloque 2Bloque 3Bloque 4Bloque 5Referencias

Bloqueo Mutuo

1. Interbloqueo y representación gráfica

Figura 1: Grafo de estado de bloqueo mutuo​​

Fuente: Niqueco, 2011, https://goo.gl/KPVqdU

Cuando múltiples actividades concurrentes necesitan acceder a cierto conjunto de recursos que no admiten un
uso compartido, existe el riesgo de que haya un bloqueo mutuo, interbloqueo o deadlock, es decir que tales
procesos o hilos se suspendan esperando la ocurrencia de algún evento que solo podría ser generado por otro
proceso o hilo que también pertenece a ese mismo conjunto de actividades bloqueadas. En ese caso, ninguna de
esas actividades podrá continuar y si el usuario o el administrador no lo remedian, esta situación problemática se
mantendrá indefinidamente.

El bloqueo mutuo puede ser representado por un grafo dirigido, en donde tanto el proceso (representado por un
círculo) como el recurso (representado por un cuadrado) son nodos del grafo. Cuando un proceso solicita un
recurso, una flecha es dirigida desde el nodo proceso al nodo recurso. Y cuando un recurso está asignado a un
proceso, la flecha se dirige del recurso al proceso (Henry, 2016).

En la Figura 1 (grafo de estado de bloqueo mutuo), se puede ver una ilustración en donde dos procesos
diferentes (A y B), cada uno con un recurso diferente asignado (R1 y R2), muestran un claro ejemplo de bloqueo
mutuo dada la condición de espera circular en la que los procesos se encuentran (cada uno requiere un recurso
que está asignado a otro proceso) (Ramírez Araujo, 2014).

El bloqueo mutuo, interbloqueo o deadlock (también conocido como traba mortal o abrazo mortal) es un
estado en el que cada miembro de un conjunto de procesos o hilos de ejecución está esperando que algún otro
miembro tome medidas, como enviar un mensaje o, más comúnmente, liberar un bloqueo. Es lo que se conoce
también como un estado de competencia (Beltrán, 2014).

2. Condiciones necesarias o condiciones de Coffman

Las condiciones de Coffman son condiciones que no son totalmente independientes entre ellas y deben
cumplirse simultáneamente para que se presente un interbloqueo. Su primera descripción fue en 1971 en un
artículo escrito por Edward G. Coffman.

Considerando los procesos P0, P1, ..., Pn y los recursos R0, R1, ..., Rm, el interbloque se presenta si:

1. Condición de exclusión mutua: existencia de al menos de un recurso compartido por los procesos, al cual
solo puede acceder uno simultáneamente.
 2. Condición de retención y espera: esta condición se presenta cuando al menos un proceso Pi toma un
recurso Ri y lo retiene durante la espera al menos un recurso Rj que previamente fue tomado por otro
proceso.
3. Condición de no expropiación: un proceso Pi, al tomar un recurso, lo tiene bloqueado, es decir que otro
proceso Pj no puede tomarlo o expropiarlo, o bien, dicho de otra forma, los recursos solo podrán ser
liberados voluntariamente por los procesos que los tienen tomados.
4. Condición de espera circular: esta condición se presenta cuando, en el conjunto de procesos P0 ...Pm
(subconjunto del total de procesos original), el proceso P0 queda en espera de un recurso tomado por P1,
que está en espera de un recurso tomado por P2, ..., que está en espera de un recurso tomado por Pm, y
que este último está en espera de un recurso tomado por P0 (la condición de retención y espera está
implicada en la condición de espera circular).

3. Semáforos
Fueron creados como un nuevo tipo de variable en 1968 por Dijkstra, para permitir resolver la mayoría de los
problemas de sincronización entre procesos. Los semáforos forman parte del diseño de muchos sistemas
operativos y lenguajes de programación diseñados para la concurrencia (“Programación concurrente”, s. f.).

Un semáforo binario S es un indicador de condición que registra si un recurso está disponible o no y, por ello,
solo puede tomar dos valores: 0 y

1. Si un semáforo binario tiene asignado el valor 1(S = 1), quiere decir que el recurso está disponible y la tarea lo
puede utilizar; por el contrario, si tiene el valor 0 asignado (S = 0), el recurso no está disponible y la tarea debe
esperar (Silberschatz, Galvin y Gagne, 2006).

Normalmente, los semáforos se implementan como una cola de tareas, a la cual se añaden (encolan) los procesos
que están en espera del recurso (“Diferencias entre hilos y procesos”, 2014).

Las operaciones permitidas sobre un semáforo son tres:

-    Inicializar

-    Espera (wait)

-    Señal (signal). (“Diferencias entre hilos y procesos”, 2014)

Es decir que podemos definir a un semáforo binario como un tipo de datos especial que solo puede tomar los
valores 0 y 1, con una cola de tareas asociada y con solo tres operaciones que pueden actuar sobre él. Estas son:

Inicializa (S: SemaforoBinario; v: integer): sirve para poner el valor del semáforo S al valor de v (los
valores posibles son 0 o 1)
Espera (S): si el valor de S es 1, lo pone en 0, pero si el de S es 0, suspende la tarea que hace la llamada y
la pone en la cola de tareas.
Señal (S): si la cola de tareas está vacía, le asigna 1 a S; si la cola no está vacía, reanuda la primera tarea
de la cola de tareas (“Diferencias entre hilos y procesos”, 2014).

Es importante comprender que la operación inicializa debe ser realizada antes de que comience la ejecución
concurrente de los procesos, debido a que su función exclusiva es dar un valor inicial al semáforo (“Diferencias
entre hilos y procesos”, 2014).

Si un proceso que corre la operación espera encuentra el semáforo valuado en 1, lo cambia a 0 y continúa su
ejecución. Si el semáforo se encuentra valuado en 0, el proceso pasa a estado de espera hasta que el semáforo
sea liberado (“Diferencias entre hilos y procesos”, 2014).

El estado de espera debe ser considerado como uno más de los posibles de un proceso, debido a que un proceso
en espera de un semáforo no está en ejecución ni listo para poder pasar a dicho estado, dado que no tiene la CPU
(unidad de procesamiento central) ni puede pasar a tenerla, mientras el semáforo no se lo indique.

La utilización de semáforos nos permite programar de una manera fácil la sincronización entre tareas. Para ello,
las operaciones de espera y señal no se utilizan dentro de un mismo proceso, sino que se dan en dos procesos
separados, es decir que el proceso que ejecuta la operación de espera queda bloqueado, hasta que la operación de
señal sea ejecutada por el otro proceso (Feldgen y Clúa, 2006).

Muchas veces se utiliza la palabra señal para denominar un semáforo usado para la sincronización de procesos,
pero, en este caso, una señal posee dos operaciones (espera y señal) que son utilizadas para sincronizar dos
procesos distintos (Müller, 2011).

4. Monitores
Un monitor es una construcción de sincronización que permite que los subprocesos tengan tanto la exclusión
mutua como la capacidad de esperar (bloquear) a que se cumpla una determinada condición. Los monitores
también tienen un mecanismo para indicar a otros subprocesos que su condición se ha cumplido. Un monitor
consta de un objeto de exclusión mutua (bloqueo) y variables de condición. Una variable de condición es
básicamente un contenedor de subprocesos que están esperando una determinada condición. Los monitores
proporcionan un mecanismo para que los subprocesos renuncien temporalmente al acceso exclusivo para esperar
a que se cumpla alguna condición, antes de recuperar el acceso exclusivo y reanudar su tarea (Mañoso, 2002).

Un monitor puede verse como una barrera alrededor de un recurso (o recursos), de tal forma que los procesos
que requieran utilizarlo deben pasar la valla, pero en la manera que requiere el monitor (Müller, 2011).

Diversos procesos pueden requerir entrar en distintos instantes de tiempo, pero solo se permite a un proceso que
entre por vez, por lo que se debe

esperar a que salga el proceso que está dentro antes de que otro pueda entrar. Los monitores presentan la ventaja
de que están implícitos para la exclusión mutua frente a los semáforos u otros mecanismos, es decir que la única
acción que debe realizar un programador de un proceso que usa un recurso es invocar una entrada del monitor
(Müller, 2011).

Si el monitor ha sido codificado de forma correcta, no puede ser utilizado indebidamente por un programa de
aplicación que desee usar el recurso indicado. Tal cosa no sucede con los semáforos, en donde el programador
debe indicar la correcta secuencia de operaciones de espera y señal para no bloquear el sistema (Müller, 2011).

Una variable que sea utilizada como mecanismo de sincronización dentro de un monitor es conocida como
variable de condición. Una variable de condición diferente debe ser asociada a cada causa diferente que ocasione
que un proceso deba esperar. Pueden actuar sobre ellas solo dos procedimientos, el de espera y señal. Cuando un
proceso ejecuta una operación de espera, se suspende su ejecución y se coloca en la cola asociada a la variable
de condición. Se diferencia con el semáforo en que ahora la ejecución de esta operación suspende el proceso que
la emite.

Esta suspensión permite que se libere la tenencia del monitor, lo cual habilita que entre otro proceso. Si un
proceso ejecuta una operación de señal, un proceso suspendido es liberado en la cola de la variable de condición
que se utiliza. De no haber proceso suspendido alguno en la cola de la variable de condición invocada, la
operación de señal no tiene ningún efecto.

5. Mensajes
La comunicación entre procesos mediante mensajes necesita tanto de un proceso emisor como de uno receptor y
de la información que se intercambia. Es debido a ello que las operaciones básicas basadas en mensajes son:
enviar (mensaje) y recibir (mensaje) y, por lo tanto, las acciones de transmisión de información y de
sincronización se ven como actividades inseparables (“Diferencias entre hilos y procesos”, 2014).

Hay aspectos importantes que deben tenerse en cuenta en la implementación, como cuántos enlaces se pueden
establecer entre los procesos, la capacidad de mensajes del enlace y el tipo de los mensajes. Cuando hablamos de
comunicación por mensajes, estamos hablando de establecer un enlace entre el receptor y el emisor. Esto puede
variar mucho dependiendo su implementación (“Diferencias entre hilos y procesos”, 2014).

La implementación varía según tres aspectos:

su modo de nombrar los procesos;

su modelo de sincronización;
el almacenamiento y la estructura del mensaje (“Diferencias entre hilos y procesos”, 2014).

Referencias
Beltrán, E. C. (2014). Bloqueo mutuo [Entrada de blog]. Recuperado de
http://sistemasoperativos142.blogspot.com/2014/10/en-sistemas- operativos-el-bloqueo-mutuo.html

Diferencias entre hilos y procesos. (2014). [Entrada de blog sin datos de autor].    Recuperado    de
https://sistemasoper2.wordpress.com/2014/10/21/diferencias-entre-hilos- y-procesos/

Feldgen, M. y Clúa, O. (2006). Capítulo 6: Programación concurrente. En Autores, Programación Java

Curso2006 – 1 C (Pp. 1-39). Facultad de Ingeniería, Universidad de Buenos Aires. Recuperado de

http://materias.fi.uba.ar/sweb/1c-2006/concurrencia.pdf

Henry (Nombre de usuario). (2016). Bloqueo mutuo [Entrada de blog]. Recuperado de

http://sistemasoperativoseinformatica.blogspot.com/2016/05/bloqueo- mutuo.html

Mañoso, C. (2002). Sincronización y comunicación [PPT en línea]. Dpto. de Informática y Automática,

Universidad Nacional de Educación a Distancia, Buenos Aires, Argentina. Recuperado de
http://www.mfbarcell.es/docencia_uned/so/tema_03/tema3.pdf

Müller, L. (2011). Programación concurrente, recopilación de teoría referente a la materia [Recopilación de la

teoría referente a la asignatura Programación Concurrente, Universidad Americana]. Recuperado de
https://docplayer.es/3083912-Programacion-concurrente-recopilacion-de- teoria-referente-a-la-materia.html

Niqueco (Nombre de usuario). (2011). Representación de un deadlock con un grafo dirigido [Imagen].
Recuperada de https://commons.wikimedia.org/wiki/File:DeadlockGraph.svg

Programación concurrente. (s. f.) [Artículo sin datos de autor]. Recuperado de

https://www.fing.edu.uy/tecnoinf/mvd/cursos/so/material/teo/so07- concurrencia.pdf

Ramírez Araujo, A. (2014). Administración de procesos y procesador [Entrada de blog]. Recuperado de

http://johannattanorberodriguez.blogspot.com/2014/05/inf-324001-07- administracion-de.html

Silberschatz, A., Galvin, P. B. y Gagne, G. (2006). Fundamentos de sistemas operativos (7.a ed.) [Versión en
línea]. Recuperado de https://es.scribd.com/document/105168144/Fundamentos-De-Sistemas- Operativos-7-
Edicion-Autor-Silberschatz-Galvin-y-Gagne-Numero-de- Paginas-828-Formato-pdf