Curso:

Sistemas Operativos
Instructor:
Ing. José Remon Girard López

Tema:
Semáforos y Monitores

Alumno:
Edgar Rolando Balán Herrarte Carnet: 1690-06-10024

Fecha:
Sábado 12 de noviembre de 2016
SEMAFOROS
Los semáforos se emplean para permitir el acceso a diferentes partes de programas (llamados
secciones críticas) donde se manipulan variables o recursos que deben ser accedidos de forma
especial. Según el valor con que son inicializados se permiten a más o menos procesos utilizar el
recurso de forma simultánea.
Un tipo simple de semáforo es el binario, que puede tomar solamente los valores 0 y 1. Se
inicializan en 1 y son usados cuando sólo un proceso puede acceder a un recurso a la vez. Son
esencialmente lo mismo que los mutex. Cuando el recurso está disponible, un proceso accede y
decremento el valor del semáforo con la operación P. El valor queda entonces en 0, lo que hace
que si otro proceso intenta decrementarlo tenga que esperar. Cuando el proceso que
decremento el semáforo realiza una operación V, algún proceso que estaba esperando
comienza a utilizar el recurso.

Para ver cómo están configurados los semáforos en nuestro sistema Solaris, debemos ejecutar
el comando sysdef, el cual nos devolverá una lista con varios parámetros del Kernel.

(root@huelva_9)# sysdef
*
* Hostid
*
*
* sun4us Configuration
*
*
* Devices
*
packages (driver not attached)
terminal-emulator (driver not attached)
deblocker (driver not attached)
obp-tftp (driver not attached)
disk-label (driver not attached)
...
*
* IPC Semaphores
*
100 semaphore identifiers (SEMMNI)
3000 semaphores in system (SEMMNS)
4096 undo structures in system (SEMMNU)
438 max semaphores per id (SEMMSL)
100 max operations per semop call (SEMOPM)
64 max undo entries per process (SEMUME)
32767 semaphore maximum value (SEMVMX)
16384 adjust on exit max value (SEMAEM)
(root@huelva_9)#
La salida de sysdef será parecida a la anterior, podemos ver en el ejemplo, que existen una serie
de línea, las cuales tienen definidos unos valores, en la siguiente tabla vamos a realizar una
correspondencia con los parámetros del Kernel y la salida de sysdef, así como una breve
descripción.

Parm. Kernel
Sysdef
Descripción
semsys:seminfo_semmni
SEMMNI
Número de identificadores de semáforos que puede tener el sistema. Corresponde al número
de sets.
semsys:seminfo_semmns
SEMMNS
Número máximo de semáforos en el sistema
semsys:seminfo_semmsl
SEMMSL
Número máximo de semáforos por ID
En nuestro ejemplo, el sistema tiene 100 Sets de semáforos y cada uno tiene 438 semáforos,
esto significa que podríamos llegar a tener 100 x 438 semáforos en el sistema, normalmente,
esta cantidad es excesiva y Solaris 9 dispone del parámetro SEMMNS para limitar el número de
semáforos que se pueden utilizar.
Cuando estemos planificando el número de semáforos que vamos a necesitar en el sistema,
tenemos que tener en cuenta:

Cuantos sets de semáforos vamos a necesitar.

Cuantos semáforos tendrá cada Set.
Que el producto de los Sets de semáforos activos y el número de semáforos activos de cada Set,
sea inferior al valor del parámetro semsys: seminfo_semmns (SEMMNS).

Una vez que conocemos como están configurados los distintos parámetros que afectan a los
semáforos en el Kernel, vamos ver qué herramientas tenemos disponibles en el sistema para
consultar el estado de los semáforos. Una de estas herramientas es el comando ipcs y la otra
herramienta, como no podía ser de otra forma, es el mdb (Modular Debugger).

El comando ipcs
Este comando nos devuelve información sobre el estado de los distintos IPCs activos en el
sistema como son, Memoria compartida, Mensajes y Semáforos, ahora solo vamos a ver como
ipcs nos puede ayudar con los semáforos, el resto de IPCs los veremos en otros artículo
dedicados a cada uno de ellos.
El man dispone de una información detallada sobre todas las opciones del comando ipcs, por lo
que no entraremos en la descripción de cada uno de ellos.
MONITORES
Un monitor es un mecanismo de alto nivel de Software para control de concurrencia que
contiene una colección de datos y los procedimientos necesarios para realizar la asignación de
un determinado recurso o grupo de recursos compartidos por varios procesos.
Son una estructura de un lenguaje de programación similar a los semáforos en cuanto a
funcionalidad, pero son más simples de manejar y controlar, son más estructurados, es decir un
tipo de dato abstracto que encapsula datos privados y proporciona métodos públicos (Monitor
= Encapsulación). La idea de un Monitor fue presentada primero por Dijkstra en 1971 donde
hizo una propuesta de una unidad de programación denominada “Secretary” para encapsular
datos compartidos, junto con los procedimientos para acceder a ellos. Posteriormente por
Brinch Hansen (1973) que propuso las clases compartidas ("shared class"), una construcción
análoga a la anterior. Luego ésto fue mejorado por Hoare y en 1974 fue quien acuñó el nombre
de “Monitor”. Posteriormente, Hansen incorpora los monitores al lenguaje Pascal concurrente
en el año 1975.
Los Monitores se caracterizan porque proveen sincronización de procesos con exclusión mutua,
es decir, que sólo se permite que un proceso puede estar activo, en el caso que se tenga un
recurso o un grupo de recursos que están siendo compartidos por un conjunto de procesos,
otorgando una solución al problema que produce la concurrencia.
Los procesos no pueden usar directamente la representación de un tipo Monitor por lo tanto
un procedimiento definido dentro de un monitor sólo tiene acceso a las variables declaradas
localmente y a los parámetros formales. De manera similar, sólo los procedimientos locales
pueden tener acceso a las variables locales de un Monitor.

Resumiendo las Características básicas de un Monitor son:

Es un Módulo de software.
Tipo Abstracto de Dato (TAD).
Mecanismo de alto nivel (impuesto por el compilador).
Estructura Fundamental de Sincronización.
Exclusión mutua (impuesta por la estructura del Monitor): sólo un proceso puede acceder al
Monitor en cada momento, cualquier otro que lo invoque debe esperar.
Variables de datos locales sólo se acceden a través de los procedimientos del Monitor.
Un proceso entra al monitor invocando uno de sus procedimientos.
Los monitores tiene distintas formas de declaración y creación según el lenguaje de
programación utilizado, así que a continuación utilizamos la siguiente notación genérica:

Estructura

Datos (privados)
Recurso compartido
Colas (“condition variable” = assertion)
Variables internas

Procedimientos (públicos)
entry()
signal()
wait()

Secuencia de inicio