TABLA DE CONTENIDOS

PAG.
1.

Introduccin..

SEMAFOROS
2.

Marco terico general.

3.

Definicin y semntica de los semforos

4.

Condicin de sincronizacin y exclusin mutua con semforos.

5.

Invariantes de los semforos.

6.

Solucin de problemas con semforos

10

7.

Simulacin de semforos...

12

7.1 Generales..

12

7.2 Binarios..

12

8.

Implementacin de semforos..

13

9.

Conclusiones

28

10.

Referencias bibliogrficas..

29

1. INTRODUCCION

La implementacin de la comunicacin y los problemas de sincronizacin asociados dependen de si

suponemos que los procesos involucrados comparten una memoria comn o si, por el contrario,
tienen la memoria distribuida, en cuyo caso se comunican mediante paso de mensajes.
Este tema nos centramos en la gestin de la comunicacin y la sincronizacin en memoria
compartida mediante semforos y monitores.
Existen dos tipos de sincronizacin bsicos: la exclusin mutua, que significa que no puede haber
dos procesos simultneamente trabajando sobre la estructura global; y las condiciones de
sincronizacin, que establecen un orden preciso en la ejecucin de las acciones. Por ejemplo, el
problema

de

la

actualizacin

mltiple

ocurre

cuando

dos

procesos

intentan

modificar

simultneamente el valor de una variable global lo que puede dar lugar a obtener resultados
incorrectos sobre la variable.
El objetivo de este trabajo es dar a conocer herramientas esenciales en la sincronizacin de tareas o
procesos, dichas herramientas basadas en variables y mtodos que controlan el grado de
concurrencia y fluidez de un programa. El trabajo esta dividido en dos partes de las cuales la primera
hace nfasis en los llamados Semforos los cuales son variables que estn formadas por un valor
numrico y una coleccin de procesos en espera y ayudan a que no se produzcan errores dentro del
programa donde es implementado.
La segunda parte de este trabajo monogrfico contara y estar asociada directamente con temas
relacionados con los Monitores, y en ella describimos las caractersticas bsicas asociadas a los
monitores como son las variables condicin, las operaciones de suspensin y reactivacin, y las
distintas disciplinas que pueden implementarse al realizar esta ultima operacin.
Con este trabajo se busca el entendimiento de mtodos y soluciones que nos atraen menos
dificultades para enfrentarnos a la complejidad del manejo del paralelismo y la concurrencia, del
mismo modo entender conceptos ligados directamente a estos temas.

2. MARCO TEORICO GENERAL

En un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo

aparentando una ejecucin simultnea. Aunque no se logra un procesamiento paralelo y produce
una sobrecarga en los intercambios de procesos, la ejecucin intercalada produce beneficios en la
eficiencia del procesamiento y en la estructuracin de los programas.
La intercalacin y la superposicin pueden contemplarse como ejemplos de procesamiento
concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad de
ejecucin de los procesos que no pueden predecirse y depende de las actividades de otros
procesos.

La concurrencia es fundamental en todas las reas para el diseo sistemas operativos. La

concurrencia comprende un gran nmero de cuestiones de diseo, incluida la comunicacin entre
procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios
procesos y asignacin del tiempo de procesador a los procesos. Se ver que estas cuestiones no
solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas
multiprogramado con un solo procesador.
La concurrencia puede presentarse en tres contextos diferentes:
Mltiples aplicaciones: la multiprogramacin se cre para permitir que el tiempo de procesador de
la mquina fuese compartido dinmicamente entre varias aplicaciones activas.
Aplicaciones estructuradas: como ampliacin de los principios del diseo modular y la
programacin estructurada, algunas aplicaciones pueden implementarse eficazmente como un
conjunto de procesos concurrentes.
Estructura del sistema operativo: las mismas ventajas de estructuracin son aplicables a los
programadores de sistemas y se ha comprobado que algunos sistemas operativos estn
implementados como un conjunto de procesos o hilos.

SEMFOROS

3. DEFINICIN Y SEMNTICA DE SEMFOROS

Un semforo es una variable especial protegida que constituye el mtodo clsico para restringir o
permitir el acceso a recursos compartidos en un entorno de multiprocesamiento. Fueron inventados
por Edsger Dijkstra y se usaron por primera vez en el sistema operativo THEOS. [WIKP10]
Son componentes de muy bajo nivel de abstraccin, de fcil comprensin y con una gran capacidad
funcional. Son unos componentes que por su bajo nivel de abstraccin resultan muy peligrosos de
manejar y frecuentemente son causa de muchos errores. Los semforos se implementan con una
cola de tareas o de condicin a la cual se aaden los procesos que estn en espera del recurso.
Como cualquier tipo de datos, queda definido por:

Conjunto de valores que se le pueden asignar.

Conjunto de operaciones que se le pueden aplicar.

Un semforo tiene asociada una lista de procesos, en la que se incluyen los procesos suspendidos
a la espera de su cambio de estado.
En funcin del rango de valores que puede tomar, los semforos se clasifican en:
Semforos binarios: Pueden tomar solo los valores 0 y 1.
var mutex: BinSemaphore;

Semforos generales: Puede tomar cualquier valor Natural (entero no negativo).

var escribiendo: Semaphore;

Un semforo puede tomar valores enteros no negativos (esto es, el valor 0 o un valor entero
positivo). La semntica de estos valores es: 0 semforo cerrado, y >0 semforo abierto.
Frecuentemente, el que un semforo sea binario o general, no es funcin de su estructura interna
sino de cmo el programador lo maneja. [CTRR10]

UN SEMFORO:
var p: semaphore;

Admite dos operaciones seguras:

Wait (p): Si el semforo no es nulo (abierto) decrementa en uno el valor del semforo. Si el valor
del semforo es nulo (cerrado), el thread que lo ejecuta se suspende y se encola en la lista de
procesos en espera del semforo.
Pseudocdigo de la operacin: wait(p);
if p>0
then p:= p-1;
else Suspende el proceso y lo encola en la lista del semforo.

La operacin wait (como la semntica de su nombre indica) es una potencial causa de retraso en
la ejecucin de un proceso. Sin embargo, es importante resaltar que no siempre que se ejecute
una sentencia wait se produce el retraso, sino solo cuando al ejecutarla, el semforo este
cerrado, esto es tiene el valor 0.

Signal (p): Si hay algn proceso en la lista de procesos del semforo, activa uno de ellos para
que ejecute la sentencia que sigue al wait que lo suspendi. Si no hay procesos en espera en la
lista incrementa en 1 el valor del semforo.
Pseudocdigo de la operacin: signal (p);
if Hay algn proceso en la lista del semforo
then Activa uno de ellos
else p:= p+1;

La ejecucin de la operacin signal (p) nunca provoca una suspensin del thread que lo ejecuta. Si
hay varios procesos en la lista del semforo, la operacin signal solo activa uno de ellos. Este se
elige de acuerdo con un criterio propio de la implementacin (FIFO, LIFO, Prioridad, etc.).
Lo importante del semforo es que se garantiza que la operacin de chequeo del valor del semforo,
y posterior actualizacin segn proceda, es siempre segura respecto a otros accesos concurrentes.
[FOAR06]

UN SEMFORO:
var p: semaphore;
Admite una operacin no segura:

initial(p, Valor_inicial): Asigna al semforo p el valor inicial que se pasa como argumento. Esta
operacin es no segura y por tanto debe ser ejecutada en una fase del programa en la que se
tenga asegurada que se ejecuta sin posibilidad de concurrencia con otra operacin sobre el
mismo semforo. [CTRR10]
4. CONDICIN DE SINCRONIZACIN Y EXCLUSIN MUTUA CON SEMFOROS

Condicin de Sincronizacin
var datoDisponible:
process Productor;
var dato: Tipo_Dato;
begin
repeat repeat
produceDato(var dato);
dejaDato(dato);
signal(datoDisponible);
forever;
end:
process Consumidor;
var dato: Tipo_Dato;
begin
repeat
wait(datoDisponible);
tomaDato(var dato);
consume(dato);
forever;
end;

Este representa una implementacin del problema de productor consumidor con buffer ilimitado.
La condicin de buffer ilimitado solo no introduce lmite a la operacin del productor. La nica
restriccin es la del consumidor (este no puede tomar el dato si este no se ha producido). Esta
restriccin se formula en funcin de la condicin de sincronizacin:
e ! (produccini consumisini)
El problema que se plantea es que el consumidor debe esperar sin leer el buffer hasta tanto que el
dato que corresponda haya sido previamente colocado. Obviamente, el consumidor es el que tiene
que esperar en este caso, luego debe contener una sentencia wait.
Esta versin resuelve el problema productor consumidor entre dos procesos. Sin embargo no prev
la posibilidad de que en el caso de que existan varios productores y varios consumidores, estos no

pueden dejar simultneamente el dato en el buffer o no puedan tomar simultneamente el dato del
buffer. Un problema se va a producir si las actividades Dejar_dato y Tomar_dato no son atmicas.
Condicin de exclusin mutua
program Exclusion_Mutua;
var mutex: binsemaphore;
process type Proceso;
begin
repeat
wait(mutex);
(* Cdigo de la seccin crtica *)
signal(mutex);
forever;
end;
var p, q, r: Proceso;
begin
initial(mutex,1);
cobegin p; q; r; coend;
end;

Se plantea una solucin del problema de exclusin mutua entre tres procesos P, Q y R, respecto de
una seccin crtica dada. Se va a utilizar un semforo Seccion_Libre" para controlar el acceso a la
misma.
El valor del semforo indica el nmero de procesos que se encuentran ejecutando la seccin crtica.
Cuando toma el valor 0, significa que algn proceso est en su seccin crtica, mientras que cuando
toma el valor 1 significa que no hay ningn proceso ejecutndola. La estructura del programa
garantiza que el semforo es binario, y nunca tomar un valor superior a 1.
De acuerdo con la semntica expuesta, el semforo debe ser inicializado al valor 1, ya que al
comenzar, ningn proceso se encuentra en la zona crtica.
Cuando uno de los procesos va a iniciar su seccin crtica, ejecuta una sentencia wait. Si no hay otro
proceso ejecutando la seccin crtica, el proceso accede directamente a Ejecutarla sin necesidad de
ninguna espera. En caso contrario, se incorpora a la lista asociada al semforo en espera de que le
toque su turno de ejecucin de la seccin crtica.
Cuando uno de los procesos concluye la ejecucin de su seccin crtica, ejecuta una sentencia
signal y continua la ejecucin de las sentencias posteriores a esta, sin esperar mayor confirmacin.
Con la ejecucin de la sentencia signal el semforo analiza la lista de procesos en espera, y si hay al
menos uno en ella, le activa y le permite concluir la sentencia wait que lo introdujo en la lista.
[CTRR10]
CRITICA DE LOS SEMAFOROS
Ventajas de los semforos:

Resuelven todos los problemas que presenta la concurrencia.

Estructuras pasivas muy simples.
Fciles de comprender.
Tienen implementaciones muy eficientes.

Desventajas o peligros de los semforos:

Son de muy bajo nivel y un simple olvido o cambio de orden conducen a bloqueos.
Requieren que la gestin de un semforo se distribuya por todo el cdigo. La depuracin de
los errores en su gestin es muy difcil.

Los semforos son los componentes bsicos que ofrecen todas las plataformas hardware y software
como base para construir los mecanismos de sincronizacin. Las restantes primitivas se basan en su
uso implcito. [FOAR06]

5. INVARIANTES DE LOS SEMAFOROS

Semforos binarios

Propiedad invariante de los semforos

Sea el semforo s, entonces se satisface:
s = valor inicial + #V(s) - #P(s) 1

Semforos generales

Propiedad invariante de los semforos

Sea el semforo general s, entonces se satisface:
s = valor inicial + #V(s) - #P(s)
En definitiva, el invariante de los semforos expresa que:
1. No se pueden recibir seales ms rpidamente de lo que se envan.
2. El nmero de seales enviadas a un semforo y no recibidas no puede exceder de la
capacidad del semforo. [MONC10]

6. SOLUCION A PROBLEMAS CON LOS SEMAFOROS

Problema Lectores-Escritores

Caso base de datos

Varios lectores pueden accesar registro datos simultneamente
Slo un escritor puede escribir
Algoritmo Lector-Escritor (I)

Hay un objeto de datos (fichero

de texto) que es utilizado por
varios procesos, unos leen y otro
que escribe.

Solo puede utilizar el recurso un

proceso y solo uno, es decir, o bien un proceso estar escribiendo o bien leyendo, pero nunca
ocurrir simultneamente (teniendo en cuenta que si no lo esta utilizando nadie, tendr
preferencia el escritor ante el lector).

Existe el algoritmo de lector/escritor sin prioridad y con prioridad al lector y otro con prioridad al
escritor.

Algoritmo Lector-Escritor (II)

Algoritmo Lector/Escritor (Prioridad lector)
//IS: Inicializa Semforo
IS(EM, 1)
IS(DB, 0)
NL = 0
Escritor(){
Hace_Algo()
Down(DB)
Escribe()
Up(DB)
Hace_mas()
}

[DOPE09]

Lector(){
Hace_Cosas()
Down(EM)
NL = NL +1
if(NL = 1) then
Down(DB)
Up(EM)
Leer()
Down(EM)
NL = NL -1
if(NL = 0) then
Up(DB)
Up(EM)

Problema Productor-Consumidor

Un buffer en memoria con N slots disponibles

Necesita llevar cuenta de tems en buffer
Productor produce tems a ingresar al buffer
Consumidor consume tems del buffer

Algoritmo Productor-Consumidor
//IS: Inicializa Semforo
Productor(){
IS(lleno, 0)
IS(vacio, 7)
IS(EM, 1)
repeat
hace_cosas()
x = produce()
Down(vacio)
Down(EM)
Push(x)
Up(EM)
Up(lleno)
Hace_mas_cosas()
untilFIN
}
Consumidor(){
repeat
Hace_algo()
Down(lleno)
Down(EM)
y = Pop()
Up(EM)
Up(vacio)
consume();
UntilFin
}

[DOPE09]
7. SIMULACION DE SEMAFOROS

7.1.

Generales
Un semforo general es una variable que toma valores 0, 1, 2, y que slo puede ser
accedida por dos procedimientos predeterminados con los siguientes efectos:

P(s)
1. si s=0 entonces se suspende la ejecucin hasta que se ejecute una operacin signal
2. si s>0 entonces s := s-1
V(s)
1. si alguna llamada wait est suspendida, se selecciona una llamada suspendida para
su reanudacin
2. si no hay llamadas suspendidas entonces s:= s+1

7.2.

Binarios

Slo pueden tomar dos valores: 0 o 1

Generalmente se inicializan con un valor de 1.
Son usados por dos o ms procesos para garantizar que slo uno puede entrar en
seccin crtica.
Antes de entrar a seccin crtica un proceso ejecuta un P(S) y un V(S) antes de salir de
ella.
Estructura de cada proceso:

8. IMPLEMENTACIN DE LOS SEMFOROS

La clave para implementar semforos es disponer de un mecanismo
(lock y unlock) que permita garantizar las secciones crticas de las
primitivas wait y signal.
Alternativas para implementarlos mecanismos lock y unlock:

Inhibicin de las interrupciones de planificacin.

Utilizar las instrucciones especiales (TAS) de que estn dotadas la
CPU.

El mecanismo clave, para poder realizar semforos, es disponer de

algn mecanismo que garantice que las secciones crticas de las
primitivas wait y signal, se hacen en exclusin mutua con otros
procesos que ejecuten estas primitivas sobre el mismo semforo. Para ello introducimos dos
primitivas "lock" y "unlock" que realizan esta funcin.
Tres alternativas para implementar las operaciones bsicas lock y unlock son:

Un mtodo software basado en un protocolo. Estos mtodos presentan el problema de

utilizar una espera activa, y en consecuencia son muy poco eficiente.

Inhibir las interrupciones que en el sistema operativo atiende los eventos de reloj y que
inducen los cambios de contexto por tiempo.

Utilizar instrucciones especiales de las que estn dotadas el hardware de la CPU, tales
como TAS (Test and set), que permiten en una operacin indescomponible, que verificar el
estado y establecer el nuevo valor de acuerdo con l.

Los semforos son tiles para:

Sincronizacin de procesos
-Para realizar una tarea, un proceso debe esperar hasta que otro anterior -haya
completado su actividad.

Garantizar la exclusin mutua

-Supongamos que dos procesos desean escribir en la pantalla
-Es necesaria la exclusin mutua para garantizar una salida correcta

Para gestionar correctamente los recursos compartidos

-Debemos asegurar que no son utilizados ms recursos que los disponibles.
-Es una generalizacin de la exclusin mutua (un solo recurso)

[CTRR10]
Implementacin de Semforo en Java

publicclassSemaforo{
privateintvalor;
/** Create a new instance of Semaforo*/
publicSemaforo(intv) {
valor = v;
}
publicsynchronizedvoidup(){
valor++;
notify();
}
}

publicsynchronizedvoidup
({
valor++;
notify();
}
}

publicsynchronizedvoiddown(){
while(valor <= 0){
try{
wait();
}catch(InterruptedExceptione){
;
}
}
valor--;
}

Otra implementacin de los semforos:

package Semaphore_Package is
type Semaphore is private;
type Binary_Semaphore is private;
function Init(N: Integer) return Semaphore;
procedure Wait (S: Semaphore);
procedure Signal(S: Semaphore);
function Init(N: Integer) return Binary_Semaphore;
procedure Wait (S: Binary_Semaphore);
procedure Signal(S: Binary_Semaphore);
Bad_Semaphore_Initialization: exception;
end Semaphore_Package;
[DOPE09]

9. CONCLUSIONES
Al finalizar esta monografa sobre semforos y monitores, se pueden textualizar las
siguientes conclusiones:

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.
La atomicidad es una caracterstica principal de los semforos y garantiza que al iniciar
una operacin con un semforo, ningn otro proceso puede tener acceso al semforo
hasta que la operacin termine o se bloquee.
Solo un proceso puede estar activo en un monitor en cada momento.
Al hacer automtica la exclusin mutua de regiones crticas, los monitores provocan que la
programacin paralela sea mucho menos propensa a error que con los semforos.
Los monitores son un concepto de un lenguaje de programacin. El compilador debe
reconocerlos y debe arreglrselas de alguna manera para lograr la exclusin mutua. La
mayora de los lenguajes no tienen monitores.

 Cuando un procedimiento monitor descubre que no puede proseguir, realiza una

operacin WAIT con alguna variable de condicin y tambin permite que entre ahora otro
proceso al que ya antes se le haba negado la entrada.
Los semforos son se un nivel muy bajo y los monitores no son utilizables salvo en unos
cuantos lenguajes de programacin y ninguna de las primitivas ofrece intercambio de
informacin entre mquinas.

10. REFERENCIAS BIBLIOGRAFICAS

SEMAFOROS

[FOAR06]

FORMELLA Arno. Programacin Concurrente, Universidad de Vigo, Departamento de

Informtica, 2006.

[WIKP10]

WIKIPEDIA. Semforos y sistemas operativos. Wikimedia Foundation, Inc. Fecha de

Actualizacin: 2010-Julio-16. Fecha de Consulta: 2010-Junio-21. Disponible en:
http://es.wikipedia.org/wiki/Sem%C3%A1foro_(inform%C3%A1tica)

[CTRR10]

CTR-COMPUTADORES Y TIEMPO REAL. Monitores. Encargado del sitio: Javier

Gutirrez.
Fecha
de
Consulta:
2010-Junio-20.
Disponible
en:
http://www.ctr.unican.es/asignaturas/procodis_3_II/Doc/Procodis_2_03.pdf

[DOPE09]

DOMINGO Pedro. Semforos. Universidad de San Carlos de Guatemala. Ao de

creacin: 2009. Fecha de Consulta: 2010-Junio-26. Disponible en:

http://www.scribd.com/doc/15256170/Semaforos-Concurrencia.pdf/

MONITORES
[MART90]

PREZ Martnez. Jorge E. Programacin Concurrente, 2 Edicin corregida, Editorial

Rueda, 1990.

[WIKI10]

WIKIPEDIA. Monitores y Concurrencia. Wikimedia Foundation, Inc. Fecha de

Actualizacin: 2010-Julio-16. Fecha de Consulta: 2010-Junio-21. Disponible en:
http://es.wikipedia.org/wiki/Monitor_(concurrencia)/

[MONC10]

MONCLS Roger. Apuntes de Programacin. Grupo Canceller, Fecha de Actualizacin:

2010-Enero-18.
Fecha
de
Consulta:
2010-Junio-23.
Disponible
en:
http://www.iued.uned.es/users/Enlaces/Apuntes/PrCo2.zip

[GALL09]

GALLARDO Melgarejo Mara del Mar. Programacin Concurrente. Departamento de

Lenguajes y Ciencias de la Computacin. Fecha de Fecha de Consulta: 2010-Junio-21.
Disponible en: http://www.lcc.uma.es/~gallardo/temaCLASE.pdf

[UTFS10]

UNIVERSIDAD TECNICA FEDERICO SANTA MARIA. Implementacin de Monitores

con Semforos. Departamento de Informtica. Wikimedia Foundation, Inc. Fecha de
Actualizacin: 2010-Julio-16. Fecha de Consulta: 2010-Junio-21. Disponible en:
http://www.inf.utfsm.cl/~rmonge/so/resueltos-coordinacion.pdf

[UDEC10]

UNIVERSIDADE DA CORUA. Monitores. Departamento de Ciencias de la

Computacin. Fecha de Actualizacin: 2010-Julio-16. Fecha de Consulta: 2010-Junio21.
Disponible
en:
http://www.dc.fi.udc.es/ai/~soto/sist_oper/monitores.htm#_Toc37051922

[ICTD10]

INSTITUTO DE INVESTIGACIONES CIENTIFICAS Y TECNICAS PARA LA DEFENSA.

Monitores. Departamento de Computacin. Fecha de Actualizacin: 2010-Julio-16.
Fecha
de
Consulta:
2010-Junio-21.
Disponible
en:
http://www.citefa.gov.ar/si6/descargas/ITBA-Monitors-Bertacchini.ppt

[CTRT10]

CTR-COMPUTADORES Y TIEMPO REAL. Monitores. Encargado del sitio: Javier

Gutirrez.
Fecha
de
Consulta:
2010-Junio-25.
Disponible
en:
http://www.ctr.unican.es/asignaturas/procodis_3_II/Doc/Procodis_2_05.pdf

[EPSA10]

UNIVERSIDAD DE ALICANTE - EPSA. Programacin Concurrente y Monitores.

Departamento de Lenguajes y Sistemas Informticos. Fecha de Consulta: 2010-Junio28. Disponible en: http://www.dlsi.ua.es/~abia/PC/material/p-concurrente.pdf