UNIVERSIDAD DE PANAM

CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS

FACULTAD DE INFORMTICA, ELECTRNICA Y
COMUNICACIN

MONOGRAFA:

SEMFOROS

PRESENTA:

ISMAEL HIDALGO

2017
 TABLA DE CONTENIDOS
1. INTRODUCCIN .............................................................................................. 1

2. DEFINICIN Y SEMNTICA DE LOS SEMFOROS ........................................ 2

2. CONDICIN DE SINCRONIZACIN Y EXCLUSIN MUTUA CON

SEMFOROS ......................................................................................................... 4

3. INVARIANTES DE LOS SEMFOROS ............................................................ 9

4. SOLUCIN DE PROBLEMAS CON SEMFOROS ....................................... 10

4.1 EL BUFFER LIMITADO............................................................................ 10

4.2 LECTORES Y ESCRITORES .................................................................. 14

4.3 LOS FILSOFOS COMENSALES ........................................................... 20

4.4 EL PUENTE DE UN SOLO CARRIL ........................................................ 26

4.5 EL BARBERO DORMILN ...................................................................... 28

4.6 LOS CANBALES COMENSALES ........................................................... 34

4.7 EL PROBLEMA DE SANTA CLAUS ........................................................ 37

5. SIMULACIN DE SEMFOROS GENERALES CON SEMFOROS

BINARIOS ............................................................................................................. 42

6. IMPLEMENTACIN DE SEMFOROS .......................................................... 45

7. CONCLUSIONES ........................................................................................... 50

8. REFERENCIAS BIBLIOGRFICAS ............................................................... 51

 TABLA DE ILUSTRACIONES
ILUSTRACIN 1: DEFINICIN DE WAIT ............................................................... 4
ILUSTRACIN 2: DEFINICIN DE SIGNAL........................................................... 4
ILUSTRACIN 3: EJEMPLO DE SINCRONIZACIN ENTRE PROCESOS
MEDIANTE SEMFOROS. ..................................................................................... 5
ILUSTRACIN 4: SOLUCIN AL PROBLEMA DE EXCLUSIN MUTUA VA
SEMFOROS ......................................................................................................... 7
ILUSTRACIN 5: UN IGL SEMFORO ............................................................... 8
ILUSTRACIN 6: TEOREMA DE INVARIANTES DE SEMFOROS ..................... 9
ILUSTRACIN 7: ESQUEMA GRFICO DEL PROBLEMA DEL BUFFER
LIMITADO ............................................................................................................. 10
ILUSTRACIN 8: PROCESOS PRODUCTOR Y CONSUMIDOR
SINCRONIZADOS MEDIANTE UN SEMFORO. ................................................ 12
ILUSTRACIN 9: APLICACIN DEL PATRN MUTEX PARA ACCEDER A LA
VARIABLE COMPARTIDA CONT. ........................................................................ 12
ILUSTRACIN 10: PATRN SEALIZACIN PARA LA SERIALIZACIN DE
EVENTOS. ............................................................................................................ 13
ILUSTRACIN 11: PSEUDOCDIGO DE LOS PROCESOS LECTOR Y
ESCRITOR. ........................................................................................................... 15
ILUSTRACIN 12: PSEUDOCDIGO DE LOS LECTORES Y ESCRITORES SIN
STARVATION. ...................................................................................................... 16
ILUSTRACIN 13: IMPLEMENTACIN DEL PATRN INTERRUPTOR............. 19
ILUSTRACIN 14: REPRESENTACIN GRFICA DEL PROBLEMA DE LOS
FILSOFOS COMENSALES. ............................................................................... 20
ILUSTRACIN 15: SOLUCIN DEL PROBLEMA DE LOS FILSOFOS
COMENSALES CON RIESGO DE INTERBLOQUEO. ......................................... 21
ILUSTRACIN 16: PROBLEMA DE LOS FILSOFOS CON CUATRO
COMENSALES EN LA MESA. .............................................................................. 21
ILUSTRACIN 17: SOLUCIN DEL PROBLEMA DE LOS FILSOFOS
COMENSALES SIN RIESGO DE INTERBLOQUEO. ........................................... 22
ILUSTRACIN 18: PSEUDOCDIGO DE LA SOLUCIN DEL PROBLEMA DE
LOS FILSOFOS COMENSALES SIN INTERBLOQUEO. .................................. 23
ILUSTRACIN 19: VARIACIN CON UNA BANDEJA AL CENTRO DEL
PROBLEMA DE LOS FILSOFOS COMENSALES. ............................................ 24
ILUSTRACIN 20: PATRN MULTIPLEX PARA EL ACCESO CONCURRENTE
DE MLTIPLES PROCESOS. .............................................................................. 25
ILUSTRACIN 21: ESQUEMA GRFICO DEL PROBLEMA DEL PUENTE DE UN
SOLO CARRIL. ..................................................................................................... 26
ILUSTRACIN 22: PROCESO COCHENORTE. .................................................. 28
ILUSTRACIN 23: SECUENCIA DE PASOS PARA DISEAR UNA SOLUCIN
ANTE UN PROBLEMA DE SINCRONIZACIN. ................................................... 30
ILUSTRACIN 24: PSEUDOCDIGO DE LA SOLUCIN AL PROBLEMA DEL
BARBERO DORMILN. ....................................................................................... 32
ILUSTRACIN 25: PATRN RENDEZVOUS PARA LA SINCRONIZACIN DE
DOS PROCESOS EN UN DETERMINADO PUNTO. ........................................... 33
ILUSTRACIN 26: PROCESO COCINERO. ........................................................ 35
ILUSTRACIN 27: PROCESO CANBAL. ............................................................ 36
ILUSTRACIN 28: PROCESO SANTA CLAUS.................................................... 39
ILUSTRACIN 29: PROCESO RENO. ................................................................. 40
ILUSTRACIN 30: PROCESO DUENDE. ............................................................ 41
ILUSTRACIN 31: MODELO DE FUNCIONAMIENTO DE UN SEMFORO. ...... 42
ILUSTRACIN 32: DEFINICIN FORMAL DE LOS SEMFOROS. .................... 43
ILUSTRACIN 33: DEFINICIN FORMAL DE LOS SEMFOROS BINARIOS. .. 44
ILUSTRACIN 34: IMPLEMENTACIN DE SEMFOROS UTILIZANDO
SOLUCIONES BASADAS EN HARDWARE. ........................................................ 46
ILUSTRACIN 35: PRIMITIVA SEM_OPEN EN POSIX. ...................................... 47
ILUSTRACIN 36: PRIMITIVAS SEM_CLOSE Y SEM_UNLINK EN POSIX. ...... 48
ILUSTRACIN 37: PRIMITIVAS SEM_WAIT Y SEM_POST EN POSIX. ............. 48
ILUSTRACIN 38: INTERFAZ DE GESTIN DE SEMFOROS. ........................ 49
 1. INTRODUCCIN
La necesidad de ofrecer concurrencia en el acceso a los recursos
computacionales se remonta a los primeros sistemas operativos.

Aprovechar al mximo los recursos computacionales fue una necesidad

apremiante, sobre todo en la poca en que las computadoras eran caras y
escasas; el sistema operativo tena que ofrecer la ejecucin concurrente y segura
de programas de varios usuarios, que desde distintas terminales utilizaban un solo
procesador, y as surgi la necesidad de introducir algunos conceptos de
programacin concurrente para programar los sistemas operativos.

En esta monografa se consideran los aspectos ms importantes que definen a los

semforos, que hoy da se consideran los mecanismos que se usan en el sistema
operativo y en los lenguajes de programacin para dar soporte a la concurrencia.
 2

2. DEFINICIN Y SEMNTICA DE LOS SEMFOROS

Se vuelven a considerar ahora los mecanismos que se usan en el sistema
operativo y en los lenguajes de programacin para dar soporte a la concurrencia.

El primer gran avance en la resolucin de los problemas de procesos

concurrentes lleg en 1965, con el tratado de Dijkstra sobre la cooperacin entre
procesos secunciales [DIJK65] Dijkstra estaba interesado en el diseo de un
sistema operativo como un conjunto de procesos secunciales cooperantes y en
el desarrollo de mecanismos eficientes y fiables para dar soporte a la
cooperacin. Los procesos de usuario podrn utilizar estos mecanismos en tanto
que el procesador y el sistema operativo los hagan disponibles.

El principio fundamental es el siguiente: Dos o ms procesos pueden cooperar

por medio de simples seales, de forma que se pueda obligar a detenerse a un
proceso en una posicin determinada hasta que reciba una seal especfica.
Cualquier requisito complicado de coordinacin puede satisfacerse por medio de
la estructura de seales adecuada. Para la sealizacin, se usan variables
especiales llamados semforos. Para transmitir una seal por el Semforo, los
procesos ejecutan la primitiva signal(s). Para recibir una seal del semforo, los
procesos ejecutan la primitiva wait(s); si la seal correspondiente an no se ha
transmitido, el proceso es suspendido hasta que tenga lugar la transmisin.

Para lograr el efecto deseado, se pueden contemplar los semforos como

variables que tienen un valor entero sobre el que se definen las tres operaciones
siguientes:

1. Un semforo puede inicializarse con un valor no negativo.

2. La operacin wait decrementa el valor del semforo. Si el valor se hace

negativo, el proceso que ejecuta el wait se bloquea.
 3

3. La operacin signal incrementa el valor del semforo. Si el valor no es

positivo, se des-bloquea a un proceso bloqueado por una operacin wait.

Aparte de estas tres operaciones, no hay forma de examinar o manipular los

semforos (STALLINGS, 1997).

Un semforo es una herramienta de sincronizacin genrica e independiente del

dominio del problema, ideada por Dijkstra en 1965. Bsicamente, un semforo
es similar a una variable entera pero con las tres diferencias siguientes:
1. Al crear un semforo, ste se puede inicializar con cualquier valor entero no
negativo.
Sin embargo, una vez creado, slo es posible incrementar y decrementar en uno
su valor. De hecho, no se debe leer el valor actual de un semforo.
2. Cuando un proceso decrementa el semforo, si el resultado es negativo
entonces dicho proceso se bloquea a la espera de que otro proceso incremente
el semforo.
3. Cuando un proceso incrementa el semforo, si hay otros procesos
bloqueados entonces uno de ellos se desbloquear.
Las operaciones de sincronizacin de los semforos son, por lo tanto, dos: wait y
signal. Estas operaciones tambin se suelen denominar P (del holands
Proberen) y V (del holands Verhogen).
Todas las modificaciones del valor entero asociado a un semforo se han de
ejecutar de manera atmica, es decir, de forma indivisible. En otras palabras,
cuando un proceso modifica el valor de un semforo, ningn otro proceso puede
modificarlo de manera simultnea (Vallejo Fernndez, 2016).
 4

A continuacin se muestra la definicin de wait ():

Ilustracin 1: Definicin de wait

La definicin de signal () es la siguiente:

Ilustracin 2: Definicin de signal

2. CONDICIN DE SINCRONIZACIN Y EXCLUSIN

MUTUA CON SEMFOROS
Los semforos tambin se usan para sincronizar eventos, delimitando hasta
qu punto puede llegar un proceso ejecutando su cdigo antes de que otro
proceso alcance otro punto de su cdigo. La ilustracin 3 muestra la estructura
de tres procesos (P1, P2 y P3) en base a sus instrucciones y los puntos de
sincronizacin entre dichos procesos (Vallejo Fernndez, 2016).

La sincronizacin tambin se refiere a situaciones en las que se desea evitar

que dos eventos ocurran al mismo tiempo o a forzar que uno ocurra antes o
despus que otro.
 5

Ilustracin 3: Ejemplo de sincronizacin entre procesos mediante semforos.

Un punto de sincronizacin, representado mediante lneas azules en la figura,

especifica si una instruccin de un proceso se ha de ejecutar, obligatoriamente,
antes que otra instruccin especfica de otro proceso. Para cada punto de
sincronizacin se ha definido un semforo binario distinto, inicializado a 0. Por
ejemplo, el punto de sincronizacin asociado al semforo a implica que la
operacin s1, del proceso P2, se ha de ejecutar antes que la operacin r3 para
que el proceso P1 pueda continuar su ejecucin.
 6

Adems de estos aspectos bsicos que conforman la definicin de un semforo,

es importante considerar las siguientes consecuencias derivadas de dicha
definicin:

En general, no es posible conocer si un proceso se bloquear despus de

decrementar el semforo.
No es posible conocer qu proceso se despertar, en caso de que haya
alguno bloqueado, despus de que se incremente el semforo.
Cuando se incrementa el semforo, el nmero de procesos que se
desbloquearn ser uno o cero. Es decir, no se ha de despertar algn
proceso necesariamente.

El uso de los semforos como mecanismo de sincronizacin plantea una serie

de ventajas, derivadas en parte de su simplicidad:

Los semforos permiten imponer restricciones explcitas con el objetivo

de evitar errores por parte del programador.
Las soluciones basadas en semforos son, generalmente, limpias y
organizadas, garantizando su simplicidad y permitiendo demostrar su
validez.
Los semforos se pueden implementar de forma eficiente en una gran
variedad de sistemas, fomentando as la portabilidad de las soluciones
planteadas (Vallejo Fernndez, 2016).

La ilustracin que se presenta a continuacin, muestra una solucin sencilla al

problema de la exclusin mutua por medio de semforos.
 7

Ilustracin 4: Solucin Al Problema De Exclusin Mutua Va Semforos

Sean n procesos, identificados por el array P(s). En cada proceso, se ejecuta un

wait(s) justo antes de su seccin crtica. Si el valor de s es negativo, se
suspende el proceso. Si el valor es 1, se decrementa a 0 y el proceso entra
inmediatamente en su seccin critica; puesto que s ya no es positivo, no se
permitir a ningn otro proceso entrar en su seccin critica.
El semforo se inicializa a 1. De este modo, el primer proceso que ejecute un
wait podr entrar inmediatamente en la seccin crtica, poniendo el valor de s a
0. Cualquier otro proceso que intente entras en la seccin critica La encontrar
ocupada y se bloqueara, poniendo el valor de s a -1. Cualquier nmero de
procesos puede intentar entrar; cada uno de estos intentos infructuosos origina
un nuevo decremento del valor de s.
 8

Cuando el proceso que entr al principio en su seccin critica salga, se

incrementar s y se eliminar uno de los procesos bloqueados (si los hay) de la
cola de procesos asociada al semforo, ponindolo en el estado listo. Cuando
sea planificado de nuevo por el sistema operativo, podr entrar en la seccin
critica.
El algoritmo de exclusin mutua por medio de semforos se puede ilustrar con el
modelo del igl, tal como se aprecia en la siguiente ilustracin:

Ilustracin 5: Un Igl Semforo

Adems de la pizarra, el igl tiene ahora un potente congelador. Un proceso

entra para realizar un wait, decrementa el valor de la pizarra en 1. Si el valor que
hay ahora en la pizarra no es negativo, puede entrar en su seccin critica. En
otro caso, entra en hibernacin en el congelador. Esto vaca el interior del igl,
permitiendo que otros procesos entren. Cuando un proceso ha completado su
seccin crtica, entra al igl para realizar un signal, incrementando el valor de la
pizarra en 1. Si el valor no es positivo, libera un proceso del congelador.
El programa de la Ilustracin 3 puede manejar igual de bien el requisito de que
ms de un proceso pueda entrar en su seccin crtica en un instante. Este
requisito se satisface simplemente inicializando el semforo con un valor
 9

especfico. De este modo, en cualquier instante, el valor de s.contador puede

interpretarse como sigue:
o s.contador >= 0: s.contador es el nmero de procesos que pueden
ejecutar un wait(s) sin bloquearse (si no se ejecuta ningn signal(s)
mientras tanto).
o s.contador <0: el valor absoluto de s.contador es el nmero de procesos
bloqueados en s.cola (DUTARI DUTARI, 2017).

3. INVARIANTES DE LOS SEMFOROS

Son las siguientes, y se verifican para cualquier semforo S:

S =0

S= S0 + |Signals| |Wai (1)

Donde S0 es el valor inicial no negativo del semforo, |Signals| es el nmero de

operaciones de Signal ejecutadas sobre l, y |Waits| el nmero de Wait
completados.

Los invariantes se siguen directamente de la definicin de semforo. Si un

programa rompe estos invariantes, se ha realizado una mala implementacin del
semforo.

Ilustracin 6: Teorema de Invariantes de semforos

 10

4. SOLUCIN DE PROBLEMAS CON SEMFOROS

PROBLEMAS CLSICOS DE SINCRONIZACIN
En esta seccin se plantean algunos problemas clsicos de sincronizacin y se
discuten posibles soluciones basadas en el uso de semforos. En la mayor parte
de ellos tambin se hace uso de segmentos de memoria compartida para
compartir datos (Vallejo Fernndez, 2016).

4.1 EL BUFFER LIMITADO

El problema del buffer limitado se suele denominar el problema del
productor/consumidor. Bsicamente, existe un espacio de almacenamiento
comn limitado, es decir, dicho espacio consta de un conjunto finito de huecos
que pueden contener o no elementos. Por una parte, los productores insertarn
elementos en el buffer. Por otra parte, los consumidores los extraern.
La primera cuestin a considerar es que se ha de controlar el acceso exclusivo a
la seccin crtica, es decir, al propio buffer. La segunda cuestin importante
reside en controlar dos situaciones: i) no se puede insertar un elemento cuando
el buffer est lleno y ii) no se puede extraer un elemento cuando el buffer est
vaco. En estos dos casos, ser necesario establecer un mecanismo para
bloquear a los procesos correspondientes.

Ilustracin 7: Esquema grfico del problema del buffer limitado

 11

Para controlar el acceso exclusivo a la seccin crtica se puede utilizar un

semforo binario, de manera que la primitiva wait posibilite dicho acceso o
bloquee a un proceso que desee acceder a la seccin crtica. Para controlar las
dos situaciones anteriormente mencionadas, se pueden usar dos semforos
independientes que se actualizarn cuando se produzca o se consuma un
elemento del buffer, respectivamente.
La solucin planteada se basa en los siguientes elementos:
Mutex, semforo binario que se utiliza para proporcionar exclusin mutua
para el Acceso al buffer de productos. Este semforo se inicializa a 1.
Empty, semforo contador que se utiliza para controlar el nmero de
huecos vacos del buffer. Este semforo se inicializa a n, siendo n el
tamao del buffer.
Full, semforo contador que se utiliza para controlar el nmero de huecos
llenos del buffer. Este semforo se inicializa a 0.
En esencia, los semforos empty y full garantizan que no se puedan insertar
ms elementos cuando el buffer est lleno o extraer ms elementos cuando est
vaco, respectivamente.
Por ejemplo, si el valor interno de empty es 0, entonces un proceso que ejecute
wait sobre este semforo se quedar bloqueado hasta que otro proceso ejecute
signal, es decir, hasta que otro proceso produzca un nuevo elemento en el
buffer.
La ilustracin 6 muestra una posible solucin, en pseudocdigo, del problema
del buffer limitado. Note cmo el proceso productor ha de esperar a que haya
algn hueco libre antes de producir un nuevo elemento, mediante la operacin
wait(empty)). El acceso al buffer se controla mediante wait(mutex), mientras que
la liberacin se realiza con signal(mutex).
Finalmente, el productor indica que hay un nuevo elemento mediante
signal(empty).
 12

PATRONES DE SINCRONIZACIN
En la solucin planteada para el problema del buffer limitado se pueden extraer
dos patrones bsicos de sincronizacin con el objetivo de reusarlos en
problemas similares.

Ilustracin 8: Procesos productor y consumidor sincronizados mediante un

semforo.

Ilustracin 9: Aplicacin del patrn mutex para acceder a la variable compartida

cont.

Uno de los patrones utilizados es el patrn mutex, que bsicamente permite

controlar el acceso concurrente a una variable compartida para que ste sea
exclusivo. En este caso, dicha variable compartida es el buffer de elementos. El
mutex se puede entender como la llave que pasa de un proceso a otro para que
este ltimo pueda proceder. En otras palabras, un proceso (o hilo) ha de tener
acceso al mutex para poder acceder a la variable compartida. Cuando termine
de trabajar con la variable compartida, entonces el proceso liberar el mutex.
 13

El patrn mutex se puede implementar de manera sencilla mediante un

semforo binario. Cuando un proceso intente adquirir el mutex, entonces
ejecutar wait sobre el mismo. Por el contrario, deber ejecutar signal para
liberarlo.
Por otra parte, en la solucin del problema anterior tambin se ve reflejado un
patrn de sincronizacin que est muy relacionado con uno de los principales
usos de los semforos: el patrn sealizacin. Bsicamente, este patrn se
utiliza para que un proceso o hilo pueda notificar a otro que un determinado
evento ha ocurrido. En otras palabras, el patrn sealizacin garantiza que una
seccin de cdigo de un proceso se ejecute antes que otra seccin de cdigo de
otro proceso, es decir, resuelve el problema de la serializacin.
En el problema del buffer limitado, este patrn lo utiliza el consumidor para
notificar que existe un nuevo tem en el buffer, posibilitando as que el productor
pueda obtenerlo, mediante el wait correspondiente sobre el semforo empty.

Ilustracin 10: Patrn sealizacin para la serializacin de eventos.

 14

4.2 LECTORES Y ESCRITORES

Suponga una estructura o una base de datos compartida por varios procesos
concurrentes. Algunos de estos procesos simplemente tendrn que leer
informacin, mientras que otros tendrn que actualizarla, es decir, realizar
operaciones de lectura y escritura. Los primeros procesos se denominan
lectores mientras que el resto sern escritores.
Si dos o ms lectores intentan acceder de manera concurrente a los datos,
entonces no se generar ningn problema. Sin embargo, un acceso simultneo
de un escritor y cualquier otro proceso, ya sea lector o escritor, generara una
condicin de carrera.
En otras palabras, un escritor no puede acceder a la seccin crtica si alguien, ya
sea lector o escritor, se encuentra en dicha seccin. Por otra parte, mientras un
escritor se encuentra en la seccin crtica, ninguna otra entidad puede acceder a
la misma. Desde otro punto de vista, mientras haya lectores, los escritores
esperarn y, mientras haya un escritor, los lectores no leern.
El nmero de lectores representa una variable compartida, cuyo acceso se
deber controlar mediante un semforo binario aplicando, de nuevo, el patrn
mutex. Por otra parte, es necesario modelar la sincronizacin existente entre los
lectores y los escritores, es decir, habr que considerar el tipo de proceso que
quiere acceder a la seccin crtica, junto con el estado actual, para determinar si
un proceso puede acceder o no a la misma. Para ello, se puede utilizar un
semforo binario que gobierne el acceso a la seccin crtica en funcin del tipo
de proceso (escritor o lector), considerando la prioridad de los lectores frente a
los escritores.
 15

La solucin planteada, cuyo pseudocdigo se muestra en la ilustracin 9, hace

uso de los siguientes elementos:
num_lectores, una variable compartida, inicializada a 0, que sirve para
contar el nmero de lectores que acceden a la seccin crtica.
mutex, un semforo binario, inicializado a 1, que controla el acceso
concurrente a num_lectores.

Ilustracin 11: Pseudocdigo de los procesos lector y escritor.

acceso_esc, un semforo binario, inicializado a 1, que sirve para dar

paso a los escritores.
En esta primera versin del problema se prioriza el acceso de los lectores con
respecto a los escritores, es decir, si un lector entra en la seccin crtica,
entonces se dar prioridad a otros lectores que estn esperando frente a un
escritor. La implementacin garantiza esta prioridad debido a la ltima sentencia
condicional del cdigo del proceso lector, ya que slo ejecutar signal sobre el
semforo acceso_esc cuando no haya lectores.
 16

La solucin planteada garantiza que no existe posibilidad de interbloqueo pero

se da una situacin igualmente peligrosa, ya que un escritor se puede quedar
esperando indefinidamente en un estado de inanicin (starvation) si no dejan de
pasar lectores.
PRIORIZANDO ESCRITORES
En esta seccin se plantea una modificacin sobre la solucin anterior con el
objetivo de que, cuando un escritor llegue, los lectores puedan finalizar pero no
sea posible que otro lector tenga prioridad sobre el escritor.
Para modelar esta variacin sobre el problema original, ser necesario
contemplar de algn modo esta nueva prioridad de un escritor sobre los lectores
que estn esperando para acceder a la seccin crtica. En otras palabras, ser
necesario integrar algn tipo de mecanismo que priorice el turno de un escritor
frente a un lector cuando ambos se encuentren en la seccin de entrada.

Ilustracin 12: Pseudocdigo de los lectores y escritores sin starvation.

 17

Una posible solucin consiste en aadir un semforo turno que gobierne el

acceso de los lectores de manera que los escritores puedan adquirirlo de
manera previa. En la ilustracin 10 se muestra el pseudocdigo de los procesos
lector y escritor, modificados a partir de la versin original.

Si un escritor se queda bloqueado al ejecutar wait sobre dicho semforo,

entonces forzar a futuros lectores a esperar. Cuando el ltimo lector abandona
la seccin crtica, se garantiza que el siguiente proceso que entre ser un
escritor.
Como se puede apreciar en el proceso escritor, si un escritor llega mientras hay
lectores en la seccin crtica, el primero se bloquear en la segunda sentencia.
Esto implica que el semforo turno est cerrado, generando una barrera que
encola al resto de lectores mientras el escritor sigue esperando.
Respecto al lector, cuando el ltimo abandona y efecta signal sobre
acceso_esc, entonces el escritor que permaneca esperando se desbloquea. A
continuacin, el escritor entrar en su seccin crtica debido a que ninguno de
los otros lectores podr avanzar debido a que turno los bloquear.
Cuando el escritor termine realizando signal sobre turno, entonces otro lector u
otro escritor podr seguir avanzando. As, esta solucin garantiza que al menos
un escritor contine su ejecucin, pero es posible que un lector entre mientras
haya otros escritores esperando.
En funcin de la aplicacin, puede resultar interesante dar prioridad a los
escritores, por ejemplo si es crtico tener los datos continuamente actualizados.
Sin embargo, en general, ser el planificador, y no el programador el
responsable de decidir qu proceso o hilo en concreto se desbloquear.
 18

PATRONES DE SINCRONIZACIN
El problema de los lectores y escritores se caracteriza porque la presencia de un
proceso en la seccin crtica no excluye necesariamente a otros procesos. Por
ejemplo, la existencia de un proceso lector en la seccin crtica posibilita que
otro proceso lector acceda a la misma. No obstante, note cmo el acceso a la
variable compartida num_lectores se realiza de manera exclusiva mediante un
mutex. Sin embargo, la presencia de una categora, por ejemplo la categora
escritor, en la seccin crtica s que excluye el acceso de procesos de otro tipo
de categora, como ocurre con los lectores. Este patrn de exclusin se suele
denominar exclusin mutua categrica.
Por otra parte, en este problema tambin se da una situacin que se puede
reproducir con facilidad en otros problemas de sincronizacin. Bsicamente, esta
situacin consiste en que el primer proceso en acceder a una seccin de cdigo
adquiera el semforo, mientras que el ltimo lo libera. Note cmo esta situacin
ocurre en el proceso lector. El nombre del patrn asociado a este tipo de
situaciones es lightswitch o interruptor, debido a su similitud con un interruptor
de luz (la primera persona lo activa o enciende mientras que la ltima lo
desactiva o apaga).
 19

Ilustracin 13: Implementacin del patrn interruptor.

En el caso de utilizar un enfoque orientado a objetos, este patrn se puede

encapsular fcilmente mediante una clase, como se muestra en el siguiente
listado de cdigo.
Finalmente, el uso del semforo turno est asociado a patrn barrera [5] debido
a que la adquisicin de turno por parte de un escritor crea una barrera para el
resto de lectores, bloqueando el acceso a la seccin crtica hasta que el escritor
libere el semforo mediante signal, es decir, hasta que levante la barrera.
 20

4.3 LOS FILSOFOS COMENSALES

Los filsofos se encuentran comiendo o pensando. Todos ellos comparten una
mesa redonda con cinco sillas, una para cada filsofo. En el centro de la mesa
hay una fuente de arroz y en la
mesa slo hay cinco palillos, de
manera que cada filsofo tiene
un palillo a su izquierda y otro a
su derecha.
Cuando un filsofo piensa,
entonces se abstrae del mundo
y no se relaciona con otros
filsofos. Cuando tiene
Ilustracin 14: representacin grfica del problema de
hambre, entonces intenta
los filsofos comensales.
acceder a los palillos que tiene
a su izquierda y a su derecha (necesita ambos). Naturalmente, un filsofo no
puede quitarle un palillo a otro filsofo y slo puede comer cuando ha cogido los
dos palillos. Cuando un filsofo termina de comer, deja los palillos y se pone a
pensar.
Este problema es uno de los problemas clsicos de sincronizacin entre
procesos, donde es necesario gestionar el acceso concurrente a los recursos
compartidos, es decir, a los propios palillos. En este contexto, un palillo se puede
entender como un recurso indivisible, es decir, en todo momento se encontrar
en un estado de uso o en un estado de no uso.
La solucin planteada en la ilustracin 13 se basa en representar cada palillo
con un semforo inicializado a 1. De este modo, un filsofo que intente hacerse
con un palillo tendr que ejecutar wait sobre el mismo, mientras que ejecutar
signal para liberarlo (ver listado siguiente). Recuerde que un filsofo slo puede
acceder a los palillos adyacentes al mismo. Aunque la solucin planteada
garantiza que dos filsofos que estn sentados uno al lado del otro nunca coman
 21

juntos, es posible que el sistema alcance una situacin de interbloqueo. Por

ejemplo, suponga que todos los filsofos cogen el palillo situado a su izquierda.
En ese momento, todos los semforos asociados estarn a 0, por lo que ningn
filsofo podr coger el palillo situado a su derecha.

Ilustracin 15: Solucin del problema de los filsofos comensales con riesgo de
interbloqueo.

Una de las modificaciones ms

directas para evitar un
interbloqueo en la versin clsica
del problema de los filsofos
comensales es limitar el nmero
de filsofos a cuatro. De este
modo, si slo hay cuatro
filsofos, entonces en el peor
caso todos cogern un palillo
pero siempre quedar un palillo
libre. En otras palabras, si dos
Ilustracin 16: Problema de los filsofos con
filsofos vecinos ya tienen un
cuatro comensales en la mesa.
palillo, entonces al menos uno de
ellos podr utilizar el palillo
 22

disponible para empezar a comer.

El nmero de filsofos de la mesa se puede controlar con un semforo contador,
inicializado a dicho nmero. A continuacin se muestra el pseudocdigo de una
posible solucin a esta variante del problema de los filsofos comensales. Como
se puede apreciar, el semforo sirviente gobierna el acceso a los palillos.

Ilustracin 17: Solucin del problema de los filsofos comensales sin riesgo de
interbloqueo.

Adems de evitar el deadlock, esta solucin garantiza que ningn filsofo se

muera de hambre. Para ello, imagine la situacin en la que los dos vecinos de
un filsofo estn comiendo, de manera que este ltimo est bloqueado por
ambos. Eventualmente, uno de los dos vecinos dejar su palillo. Debido a que el
filsofo que se encontraba bloqueado era el nico que estaba esperando a que
el palillo estuviera libre, entonces lo coger. Del mismo modo, el otro palillo
quedar disponible en algn instante.
Otra posible modificacin, propuesta en el libro de A.S. Tanenbaum Sistemas
Operativos Modernos, para evitar la posibilidad de interbloqueo consiste en
permitir que un filsofo coja sus palillos si y slo si ambos palillos estn
disponibles. Para ello, un filsofo deber obtener los palillos dentro de una
seccin crtica. En la ilustracin 16 se muestra el pseudocdigo de esta posible
modificacin, la cual incorpora un array de enteros, denominado estado
compartido entre los filsofos, que refleja el estado de cada uno de ellos. El
 23

acceso a dicho array ha de protegerse mediante un semforo binario,

denominado mutex.

Ilustracin 18: Pseudocdigo de la solucin del problema de los filsofos

comensales sin interbloqueo.

La principal diferencia con respecto al planteamiento anterior es que el array de

semforos actual sirve para gestionar el estado de los filsofos, en lugar de
gestionar los palillos. Note cmo la funcin coger_palillos() comprueba si el
filsofo i puede coger sus dos palillos adyacentes mediante la funcin prueba().
La funcin dejar_palillos() est planteada para que el filsofo i compruebe si los
filsofos adyacentes estn hambrientos y no se encuentran comiendo.
Note que tanto para acceder al estado de un filsofo como para invocar a
prueba(), un proceso ha de adquirir el mutex. De este modo, la operacin de
comprobar y actualizar el array se transforma en atmica. Igualmente, no es
posible entrar en una situacin de interbloqueo debido a que el nico semforo
accedido por ms de un filsofo es mutex y ningn filsofo ejecuta wait con el
semforo adquirido. Compartiendo el arroz Una posible variacin del problema
original de los filsofos comensales consiste en suponer que los filsofos
comern directamente de una bandeja situada en el centro de la mesa. Para
 24

ello, los filsofos disponen de cuatro palillos que estn dispuestos al lado de la
bandeja. As, cuando un filsofo quiere comer, entonces tendr que coger un par
de palillos, comer y, posteriormente, dejarlos de nuevo para que otro filsofo
pueda comerlos. La ilustracin 17 muestra de manera grfica la problemtica
planteada.
Esta variacin admite varias soluciones. Por ejemplo, se podra utilizar un
esquema similar al discutido en la solucin anterior en la que se evitaba el
interbloqueo. Es decir, se podra pensar una solucin en la que se comprobara,
de manera explcita, si un filsofo puede coger dos palillos, en lugar de coger
uno y luego otro, antes de comer. Sin embargo, es posible plantear una solucin
ms simple y elegante ante esta variacin.
Para ello, se puede utilizar un semforo contador inicializado a 2, el cual
representa los pares de palillos disponibles para los filsofos. Este semforo
palillos gestiona el acceso concurrente de los filsofos a la bandeja de arroz.

Ilustracin 19: Variacin con una bandeja al centro del problema de los filsofos
comensales.
 25

Ilustracin 20: Patrn multiplex para el acceso concurrente de mltiples

procesos.

PATRONES DE SINCRONIZACIN
La primera solucin sin interbloqueo del problema de los filsofos comensales y
la solucin a la variacin con los palillos en el centro comparten una
caracterstica. En ambas soluciones se ha utilizado un semforo contador que
posibilita el acceso concurrente de varios procesos a la seccin crtica.
En el primer caso, el semforo sirviente se inicializaba a 4 para permitir el
acceso concurrente de los filsofos a la seccin crtica, aunque luego
compitieran por la obtencin de los palillos a nivel individual.
En el segundo caso, el semforo palillos se inicializaba a 2 para permitir el
acceso concurrente de dos procesos filsofo, debido a que los filsofos
disponan de 2 pares de palillos.
Este tipo de soluciones se pueden encuadrar dentro de la aplicacin del patrn
multiplex, mediante el uso de un semforo contador cuya inicializacin determina
el nmero mximo de procesos que pueden acceder de manera simultnea a
una seccin de cdigo. En cualquier otro momento, el valor del semforo
representa el nmero de procesos que pueden entrar en dicha seccin.
Si el semforo alcanza el valor 0, entonces el siguiente proceso que ejecute wait
se bloquear. Por el contrario, si todos los procesos abandonan la seccin
crtica, entonces el valor del semforo volver a n.
 26

4.4 EL PUENTE DE UN SOLO CARRIL

Ilustracin 21: Esquema grfico del problema del puente de un solo carril.
Suponga un puente que tiene una carretera con un nico carril por el que los
coches pueden circular en un sentido o en otro. La anchura del carril hace
imposible que dos coches puedan pasar de manera simultnea por el puente. El
protocolo utilizado para atravesar el puente es el siguiente:
Si no hay ningn coche circulando por el puente, entonces el primer
coche en llegar cruzar el puente.
Si un coche est atravesando el puente de norte a sur, entonces los
coches que estn en el extremo norte del puente tendrn prioridad sobre
los que vayan a cruzarlo desde el extremo sur.
Del mismo modo, si un coche se encuentra cruzando de sur a norte,
entonces los coches del extremo sur tendrn prioridad sobre los del norte.
En este problema, el puente se puede entender como el recurso que comparten
los coches de uno y otro extremo, el cual les permite continuar con su
funcionamiento habitual.
Sin embargo, los coches se han de sincronizar para acceder a dicho puente.
Por otra parte, en la solucin se ha de contemplar la cuestin de la prioridad, es
decir, es necesario tener en cuenta que si, por ejemplo, mientras un coche del
norte est en el puente, entonces si vienen ms coches del norte podrn circular
por el puente. Es decir, un coche que adquiere el puente habilita al resto de
 27

coches del norte a la hora de cruzarlo, manteniendo la preferencia con respecto

a los coches que, posiblemente, estn esperando en el sur.
Por lo tanto, es necesario controlar, de algn modo, el nmero de coches en
circulacin desde ambos extremos. Si ese nmero llega a 0, entonces los
coches del otro extremo podrn empezar a circular.

Una posible solucin manejara los siguientes elementos:

Puente, un semforo binario que gestiona el acceso al mismo.

CochesNorte, una variable entera compartida para almacenar el nmero
de coches que circulan por el puente, en un determinado instante del
tiempo, desde el extremo norte.
MutexN, un semforo binario que permite controlar el acceso exclusivo a
Coches-Norte.
CochesSur, una variable entera compartida para almacenar el nmero de
coches que circulan por el puente, en un determinado instante del tiempo,
desde el extremo sur.
MutexS, un semforo binario que permite controlar el acceso exclusivo a
Coches-Sur.
En el siguiente listado se muestra el pseudocdigo de una posible solucin al
problema del puente de un solo carril. Bsicamente, si un coche viene del
extremo norte, y es el primero, entonces intenta acceder al puente invocando a
wait sobre el semforo puente.
Este planteamiento se aplica del mismo modo a los coches que provienen del
extremo sur, cambiando los semforos y la variable compartida.
 28

Ilustracin 22: Proceso CocheNorte.

El anexo A contiene una solucin completa de este problema de sincronizacin.

La implementacin de coche es genrica, es decir, independiente de si parte del
extremo norte o del extremo sur. La informacin necesaria para su correcto
funcionamiento (bsicamente el nombre de los semforos y las variables de
memoria compartida) se enva desde el proceso manager (el que ejecuta la
primitiva execl()).

4.5 EL BARBERO DORMILN

El problema original de la barbera fue propuesto por Dijkstra, aunque
comnmente se suele conocer como el problema del barbero dormiln. El
enunciado de este problema clsico de sincronizacin se expone a continuacin.
La barbera tiene una sala de espera con n sillas y la habitacin del barbero
tiene una nica silla en la que un cliente se sienta para que el barbero trabaje. Si
no hay clientes, entonces el barbero se duerme. Si un cliente entra en la
barbera y todas las sillas estn ocupadas, es decir, tanto la del barbero como
las de la sala de espera, entonces el cliente se marcha. Si el barbero est
 29

ocupado pero hay sillas disponibles, entonces el cliente se sienta en una de

ellas. Si el barbero est durmiendo, entonces el cliente lo despierta.
Para abordar este problema clsico se describirn algunos pasos que pueden
resultar tiles a la hora de enfrentarse a un problema de sincronizacin entre
procesos. En cada uno de estos pasos se discutir la problemtica particular del
problema de la barbera.
1. Identificacin de procesos, con el objetivo de distinguir las distintas
entidades que forman parte del problema. En el caso del barbero dormiln, estos
procesos son el barbero y los clientes. Tpicamente, ser necesario otro proceso
manager encargado del lanzamiento y gestin de los procesos especficos de
dominio.
2. Agrupacin en clases o trozos de cdigo, con el objetivo de estructurar a
nivel de cdigo la solucin planteada. En el caso del barbero, el cdigo se puede
estructurar de acuerdo a la identificacin de procesos.
3. Identificacin de recursos compartidos, es decir, identificacin de aquellos
elementos compartidos por los procesos. Ser necesario asociar herramientas
de sincronizacin para garantizar el correcto acceso a dichos recursos. Por
ejemplo, se tendr que usar un semforo para controlar el acceso concurrente al
nmero de sillas.
4. Identificacin de eventos de sincronizacin, con el objetivo de delimitar
qu eventos tienen que ocurrir obligatoriamente antes que otros. Por ejemplo,
antes de poder actuar, algn cliente ha de despertar al barbero. Ser necesario
asociar herramientas de sincronizacin para controlar dicha sincronizacin. Por
ejemplo, se podra pensar en un semforo binario para que un cliente despierte
al barbero.
5. Implementacin, es decir, codificacin de la solucin planteada utilizando
algn lenguaje de programacin. Por ejemplo, una alternativa es el uso de los
mecanismos que el estndar POSIX define para la manipulacin de mecanismos
de sincronizacin y de segmentos de memoria compartida.
 30

En el caso particular del problema del barbero dormiln se distinguen claramente

dos recursos compartidos:
Las sillas, compartidas por los clientes en la sala de espera.
El silln, compartido por los clientes que compiten para ser atendidos por
el barbero.

Ilustracin 23: Secuencia de pasos para disear una solucin ante un problema
de sincronizacin.

Para modelar las sillas se ha optado por utilizar un segmento de memoria

compartida que representa una variable entera. Con dicha variable se puede
controlar fcilmente el nmero de clientes que se encuentran en la barbera,
modelando las situaciones especficas en la que todas las sillas estn ocupadas
y, por lo tanto, el cliente ha de marcharse. La variable denominada num_clientes
se inicializa a 0. El acceso a esta variable ha de ser exclusivo, por lo que una
vez se utiliza el patrn mutex.
Otra posible opcin hubiera sido un semforo contador inicializado al nmero
inicial de sillas libres en la sala de espera de la barbera. Sin embargo, si
utilizamos un semforo no es posible modelar la restriccin que hace que un
 31

cliente abandone la barbera si no hay sillas libres. Con un semforo, el cliente

se quedara bloqueado hasta que hubiese un nuevo hueco. Por otra parte, para
modelar el recurso compartido representado por el silln del barbero se ha
optado por un semforo binario, denominado silln, con el objetivo de garantizar
que slo pueda haber un cliente sentado en l.
Respecto a los eventos de sincronizacin, en este problema existe una
interaccin directa entre el cliente que pasa a la sala del barbero, es decir, el
proceso de despertar al barbero, y la notificacin del barbero al cliente cuando
ya ha terminado su trabajo. El primer evento se ha modelado mediante un
semforo binario denominado barbero, ya que est asociado al proceso de
despertar al barbero por parte de un cliente. El segundo evento se ha modelado,
igualmente, con otro semforo binario denominado fin, ya que est asociado al
proceso de notificar el final del trabajo a un cliente por parte del barbero.
Ambos semforos se inicializan a 0.
En la ilustracin 22 se muestra el pseudocdigo de una posible solucin al
problema del barbero dormiln. Como se puede apreciar, la parte relativa al
proceso barbero es trivial, ya que ste permanece de manera pasiva a la espera
de un nuevo cliente, es decir, permanece bloqueado mediante wait sobre el
semforo barbero. Cuando terminado de cortar, el barbero notificar dicha
finalizacin al cliente mediante signal sobre el semforo fin. Evidentemente, el
cliente estar bloqueado por wait.
 32

Ilustracin 24: Pseudocdigo de la solucin al problema del barbero dormiln.

 33

El pseudocdigo del proceso cliente es algo ms complejo, ya que hay que

controlar si un cliente puede o no pasar a la sala de espera. Para ello, en primer
lugar se ha de comprobar si todas las sillas estn ocupadas, es decir, si el valor
de la variable compartida num_clientes ha llegado al mximo, es decir, a las N
sillas que conforman la sala de espera. En tal caso, el cliente habr de
abandonar la barbera. Note cmo el acceso a num_clientes se gestiona
mediante mutex.
Si hay alguna silla disponible, entonces el cliente esperar su turno. En otras
palabras, esperar el acceso al silln del barbero. Esta situacin se modela
ejecutando wait sobre el semforo silln. Si un cliente se sienta en el silln,
entonces deja una silla disponible.
A continuacin, el cliente sentado en el silln despertar al barbero y esperar a
que ste termine su trabajo. Finalmente, el cliente abandonar la barbera
liberando el silln para el siguiente cliente (si lo hubiera).

Ilustracin 25: Patrn rendezvous para la sincronizacin de dos procesos en un

determinado punto.

PATRONES DE SINCRONIZACIN
La solucin planteada para el problema del barbero dormiln muestra el uso del
patrn sealizacin para sincronizar tanto al cliente con el barbero como al
contrario. Esta generalizacin se puede asociar al patrn rendezvous, debido a
que el problema de sincronizacin que se plantea se denomina con ese trmino.
Bsicamente, la idea consiste en sincronizar dos procesos en un determinado
 34

punto de ejecucin, de manera que ninguno puede avanzar hasta que los dos
han llegado.
En la ilustracin 23 se muestra de manera grfica esta problemtica en la que se
desea garantizar que la sentencia a1 se ejecute antes que b2 y que b1 ocurra
antes que a2.
Note cmo, sin embargo, no se establecen restricciones entre las sentencias a1
y b1, por ejemplo.
Por otra parte, en la solucin tambin se refleja una situacin bastante comn en
problemas de sincronizacin: la llegada del valor de una variable compartida a
un determinado lmite o umbral. Este tipo de situaciones se asocia al patrn
scoreboard o marcador.

4.6 LOS CANBALES COMENSALES

En una tribu de canbales todos comen de la misma olla, la cual puede albergar
N raciones de comida. Cuando un canbal quiere comer, simplemente se sirve
de la olla comn, a no ser que est vaca. En ese caso, el canbal despierta al
cocinero de la tribu y espera hasta que ste haya rellenado la olla.
En este problema, los eventos de sincronizacin son dos:
Si un canbal que quiere comer se encuentra con la olla vaca, entonces
se lo notifica al cocinero para que ste cocine.
Cuando el cocinero termina de cocinar, entonces se lo notifica al canbal
que lo despert previamente.
Un posible planteamiento para solucionar este problema podra girar en torno al
uso de un semforo que controlara el nmero de raciones disponibles en un
determinado momento (de manera similar al problema del buffer limitado). Sin
embargo, este planteamiento no facilita la notificacin al cocinero cuando la olla
est vaca, ya que no es deseable acceder al valor interno de un semforo y, en
funcin del mismo, actuar de una forma u otra.
 35

Una alternativa vlida consiste en utilizar el patrn marcador para controlar el

nmero de raciones de la olla mediante una variable compartida. Si sta alcanza
el valor de 0, entonces el canbal podra despertar al cocinero.

La sincronizacin entre el canbal y el cocinero se realiza mediante rendezvous:

1. El canbal intenta obtener una racin.
2. Si no hay raciones en la olla, el canbal despierta al cocinero.
3. El cocinero cocina y rellena la olla.
4. El cocinero notifica al canbal.
5. El canbal come.
La solucin planteada hace uso de los siguientes elementos:
Num_Raciones, variable compartida que contiene el nmero de raciones
disponibles en la olla en un determinado instante de tiempo.
Mutex, semforo binario que controla el acceso a Num_Raciones.
Empty, que controla cuando la olla se ha quedado vaca.
Full, que controla cuando la olla est llena.
En la ilustracin 24 se muestra el pseudocdigo del proceso cocinero, el cual es
muy simple ya que se basa en esperar la llamada del canbal, cocinar y notificar
de nuevo al canbal.

Ilustracin 26: Proceso Cocinero.

 36

El pseudocdigo del proceso canbal es algo ms complejo, debido a que ha de

consultar el nmero de raciones disponibles en la olla antes de comer.
Como se puede apreciar, el proceso canbal comprueba el nmero de raciones
disponibles en la olla (lnea 4). Si no hay, entonces despierta al cocinero (lnea
5) y espera a que ste rellene la olla (lnea 6). Estos dos eventos de
sincronizacin guan la evolucin de los procesos involucrados.
Note cmo el proceso canbal modifica el nmero de raciones asignando un
valor constante. El lector podra haber optado porque fuera el cocinero el que
modificara la variable, pero desde un punto de vista prctico es ms eficiente
que lo haga el canbal, ya que tiene adquirido el acceso a la variable mediante el
semforo mutex (lneas 2 y 12).

Ilustracin 27: Proceso Canbal.

Posteriormente, el canbal decrementa el nmero de raciones (lnea 12) e

invierte un tiempo en comer (lnea 14).
 37

4.7 EL PROBLEMA DE SANTA CLAUS

Santa Claus pasa su tiempo de descanso, durmiendo, en su casa del Polo
Norte. Para poder despertarlo, se ha de cumplir una de las dos condiciones
siguientes:
1. Que todos los renos de los que dispone, nueve en total, hayan vuelto de
vacaciones.
2. Que algunos de sus duendes necesiten su ayuda para fabricar un juguete.
Para permitir que Santa Claus pueda descansar, los duendes han acordado
despertarle si tres de ellos tienen problemas a la hora de fabricar un juguete. En
el caso de que un grupo de tres duendes estn siendo ayudados por Santa, el
resto de los duendes con problemas tendrn que esperar a que Santa termine
de ayudar al primer grupo.
En caso de que haya duendes esperando y todos los renos hayan vuelto de
vacaciones, entonces Santa Claus decidir preparar el trineo y repartir los
regalos, ya que su entrega es ms importante que la fabricacin de otros
juguetes que podra esperar al ao siguiente.
El ltimo reno en llegar ha de despertar a Santa mientras el resto de renos
esperan antes de ser enganchados al trineo.
Para solucionar este problema, se pueden distinguir tres procesos bsicos: i)
Santa Claus, ii) duende y iii) reno. Respecto a los recursos compartidos, es
necesario controlar el nmero de duendes que, en un determinado momento,
necesitan la ayuda de Santa y el nmero de renos que, en un determinado
momento, estn disponibles. Evidentemente, el acceso concurrente a estas
variables ha de estar controlado por un semforo binario.
Respecto a los eventos de sincronizacin, ser necesario disponer de
mecanismos para despertar a Santa Claus, notificar a los renos que se han de
enganchar al trineo y controlar la espera por parte de los duendes cuando otro
grupo de duendes est siendo ayudado por Santa Claus.
 38

En resumen, se utilizarn las siguientes estructuras para plantear la solucin del

problema:
Duendes, variable compartida que contiene el nmero de duendes que
necesitan la ayuda de Santa en un determinado instante de tiempo.
Renos, variable compartida que contiene el nmero de renos que han
vuelto de vacaciones y estn disponibles para viajar.
Mutex, semforo binario que controla el acceso a Duendes y Renos.
SantaSem, semforo binario utilizado para despertar a Santa Claus.
RenosSem, semforo contador utilizado para notificar a los renos que
van a emprender el viaje en trineo.
DuendesSem, semforo contador utilizado para notificar a los duendes
que Santa los va a ayudar.
DuendesMutex, semforo binario para controlar la espera de duendes
cuando Santa est ayudando a otros.

En la ilustracin 29 se muestra el pseudocdigo del proceso Santa Claus. Como

se puede apreciar, Santa est durmiendo a la espera de que lo despierten (lnea
3). Si lo despiertan, ser porque los duendes necesitan su ayuda o porque todos
los renos han vuelto de vacaciones. Por lo tanto, Santa tendr que comprobar
cul de las dos condiciones se ha cumplido.
 39

Ilustracin 28: Proceso Santa Claus.

Si todos los renos estn disponibles (lnea 8), entonces Santa preparar el trineo
y notificar a todos los renos (lneas 9-12). Note cmo tendr que hacer tantas
notificaciones (signal) como renos haya disponibles. Si hay suficientes duendes
para que sean ayudados (lneas 15-20), entonces Santa los ayudar, notificando
esa ayuda de manera explcita (signal) mediante el semforo DuendesSem.
El proceso reno es bastante sencillo, ya que simplemente despierta a Santa
cuando todos los renos estn disponibles y, a continuacin, esperar la
notificacin de Santa. Una vez ms, el acceso a la variable compartida renos se
controla mediante el semforo binario mutex.
 40

Ilustracin 29: Proceso reno.

Finalmente, en el proceso duende se ha de controlar la formacin de grupos de

duendes de tres componentes antes de despertar a Santa (lnea 6). Si se ha
alcanzado el nmero mnimo para poder despertar a Santa, entonces se le
despierta mediante signal sobre el semforo SantaSem (lnea 7). Si no es as, es
decir, si otro duende necesita ayuda pero no se ha llegado al nmero mnimo de
duendes para despertar a Santa, entonces el semforo DuendesMutex se libera
(lnea 9 ).
El duende invocar a obtener Ayuda y esperar a que Santa notifique dicha
ayuda mediante DuendesSem. Note cmo despus de solicitar ayuda, el duende
queda a la espera de la notificacin de Santa (Vallejo Fernndez, 2016).
 41

Ilustracin 30: Proceso duende.

 42

5. SIMULACIN DE SEMFOROS GENERALES CON

SEMFOROS BINARIOS
Los semforos se suelen clasificar en semforos contadores y semforos
binarios.
Un semforo contador es aqul que permite que su valor pueda variar sin
restricciones, mientras que en un semforo binario dicho valor slo puede ser 0
1. Tradicionalmente, los semforos binarios se suelen denominar mutex.
(Vallejo Fernndez, 2016)

Ilustracin 31: Modelo de funcionamiento de un semforo.

La ilustracin que se presenta a continuacin propone una definicin ms formal
de las primitivas de los semforos. Las primitivas wait y signal se suponen
atmicas, es decir, no pueden ser interrumpidas y cada rutina puede
considerarse como un paso indivisible.
 43

Ilustracin 32: Definicin Formal De Los Semforos.

En tanto, en la siguiente ilustracin se define una versin ms limitada, conocida

como semforo binario. Un semforo binario solo puede tomar los valores 0 y 1.
En principio, los semforos binarios son ms sencillos de implementar y puede
demostrarse que tienen la misma potencia de expresin que los semforos
generales.
 44

Ilustracin 33: Definicin Formal De Los Semforos Binarios.

Tanto en los semforos como en los semforos binarios se emplea una cola
para mantener los procesos esperando en el semforo. La definicin no dicta el
orden en el que se quitan los procesos de dicha cola. La poltica ms equitativa
es la FIFO: el proceso que ha estado bloqueado durante ms tiempo se libera de
la cola. La nica exigencia estricta es que un proceso no debe quedar retenido
en la cola de un semforo indefinidamente porque otros procesos tengan
preferencia. (DUTARI DUTARI, 2017)
 45

6. IMPLEMENTACIN DE SEMFOROS
Como se mencion anteriormente, es imprescindible que las operaciones wait y
signal sean implementadas como primitivas atmicas. Una forma obvia es
hacerlo en el hardware o en el firmware.
Si no se puede, se han propuesto varios esquemas. La esencia del problema es
la exclusin mutua: solo un proceso puede manipular un semforo en un
instante, tanto con una operacin wait como con signal. As pues, se puede usar
cualquier esquema de software, tales como los algoritmos de Dekker o Peterson,
lo que supone una sobrecarga de proceso sustancial.
Otra alternativa es usar uno de los esquemas de soporte del hardware para la
exclusin mutua. Por ejemplo, en la siguiente ilustracin, se muestra el uso de la
instruccin Comparar y Fijar, as como de las interrupciones de hardware, para
implementar las operaciones de un semforo.
 46

Ilustracin 34: Implementacin De Semforos Utilizando soluciones Basadas En

Hardware.

En esta implementacin, el semforo est definido de nuevo con el tipo record,

como en la Ilustracin 31, pero ahora incluye un nuevo componente entero,
s.seal. Es verdad que esto implica espera activa, pero las operaciones signal y
wait son relativamente cortas, con lo que la cantidad de espera activa que se
obtiene ser menor.
En sistemas monoprocesador, se puede inhibir simplemente las interrupciones
durante una operacin wait o signal, como se propone en la ilustracin anterior.
De nuevo, la duracin relativamente corta de estas operaciones hace que esta
solucin sea razonable (DUTARI DUTARI, 2017).

En esta seccin se discuten las primitivas POSIX ms importantes relativas a la

creacin y manipulacin de semforos y segmentos de memoria compartida. As
 47

mismo, se plantea el uso de una interfaz que facilite la manipulacin de los

semforos mediantes funciones bsicas para la creacin, destruccin e
interaccin mediante operaciones wait y signal.
En POSIX, existe la posibilidad de manejar semforos nombrados, es decir,
semforos que se pueden manipular mediante cadenas de texto, facilitando as
su manejo e incrementando el nivel semntico asociado a los mismos.
En la ilustracin 34 se muestra la interfaz de la primitiva sem_open(), utilizada
para abrir un semforo nombrado.

Ilustracin 35: Primitiva sem_open en POSIX.

El valor de retorno de la primitiva sem_open() es un puntero a una estructura del
tipo sem_t que se utilizar para llamar a otras funciones vinculadas al concepto
de semforo.
 48

POSIX contempla diversas primitivas para cerrar (sem_close()) y eliminar

(sem_unlink()) un semforo, liberando as los recursos previamente creados por
sem_open(). La primera tiene como parmetro un puntero a semforo, mientras
que la segunda slo necesita el nombre del mismo.

Ilustracin 36: Primitivas sem_close y sem_unlink en POSIX.

Finalmente, las primitivas para decrementar e incrementar un semforo se

exponen a continuacin. Note cmo la primitiva de incremento utiliza el nombre
post en lugar del tradicional signal.

Ilustracin 37: Primitivas sem_wait y sem_post en POSIX.

 49

Para facilitar este proceso se ha definido una interfaz con el objetivo de

simplificar la manipulacin de dichos semforos, el cual se muestra en la
ilustracin 36.

Ilustracin 38: Interfaz de gestin de semforos.

El diseo de esta interfaz se basa en utilizar un esquema similar a los semforos

nombrados en POSIX, es decir, identificar a los semforos por una cadena de
caracteres. Dicha cadena se utilizar para crear un semforo, obtener el puntero
a la estructura de tipo sem_t y destruirlo. Sin embargo, las operaciones wait y
signal se realizarn sobre el propio puntero a semforo (Vallejo Fernndez,
2016).
 50

7. CONCLUSIONES
Al finalizar esta monografa sobre Semforos, se pueden exponer las siguientes
conclusiones:

Los semforos son una herramienta de sincronizacin y al mismo tiempo

una variable protegida, esta solo puede ser modificada por la rutina
inicializacin.
Son una herramienta que proporciona el programador que asegura la
exclusin entre procesos concurrentes para acceder a un recurso
compartido.
Se puede establecer que los semforos son una herramienta bsica, pero
potente y flexible, para hacer cumplir la exclusin mutua y coordinar
procesos.

Los semforos generales son tiles cuando un recurso ser asignado,

tomndolo de un conjunto de recursos idnticos.

Los semforos binarios estn llamados a ser implementados por dos o

ms procesos para garantizar que slo uno pueda entrar en seccin
crtica.

Si se utilizan mltiples CPU, cada semforo debe protegerse con una

variable de cierre, utilizando la instruccin TSL para asegurar que slo
una CPU a la vez examine el semforo.
 51

8. REFERENCIAS BIBLIOGRFICAS
DUTARI DUTARI, R. E. (2017). Folleto: Programacin V Inf. 300. Universidad de

Panam, Facultad de Informtica, Electrnica y Comunicacin. . Santiago:

Universidad de Panam.

FOROUZAN, B. (2002). Transmisin de Datos y Redes de Comunicaciones

(Segunda ed.). Madrid, Espaa: McGraw-Hill.

STALLINGS, W. (1997). Sistemas Operativos (Segunda ed.). Madrid, Espaa:

Prentice-Hall.

STALLINGS, W. (2004). Comunicaciones y Redes de Computadoras (Sptima

ed.). Madrid, Espaa: Pearson.

TANENBAUM, A. (2003). Computer Networks (Fourth ed.). Upper Saddle River,

U.S.A.: Pearson.

Vallejo Fernndez, G. M. (2016). Programacin Concurrente Y Tiempo Real 3ed.

Ciudad Real, Espaa: CreateSpace.

WIKIPEDIA. (12 de Febrero de 2010). Asynchronous Transfer Mode.

Recuperado el 16 de Febrero de 2010, de Wikimedia Foundation, Inc.:

http://es.wikipedia.org/wiki/Asynchronous_Transfer_Mode