manual de prÆcticas de sistemas...

Manual de Prácticas de SistemasOperativos

Curso 2004-2005

Índice general

1. Evaluación y Calendario de Prácticas 1

2. Enunciado de las Prácticas 3

2.1. Práctica 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Práctica 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Proceso santa (“santa.c”) . . . . . . . . . . . . . . . . . . . . . . . . 6

Proceso reno (“reno.c”) . . . . . . . . . . . . . . . . . . . . . . . . . 6

Proceso duende (“duende.c”) . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Práctica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.3. Ejemplos de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Introducción al Sistema Operativo Unix 11

3.1. Archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2. Disquetera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3. Depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4. LLamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Gestión de Procesos 19

4.1. Definición de Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2. Estados de un Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3. Identificación de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4. Creación de Procesos: fork() . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5. Ejecución de Procesos: execl() . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. Utilización de Semáforos en el Laboratorio 25

i

ii ÍNDICE GENERAL

6. Utilización de monitores en el laboratorio 296.1. Monitor ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2. Monitores con paso de parámetros . . . . . . . . . . . . . . . . . . . . . . . 36

Capítulo 1

Evaluación y Calendario de Prácticas

Para aprobar la parte práctica de la asignatura, es necesario entregar las prácticasen la fecha indicada, que dichas prácticas funcionen y responder correctamente a algunaspreguntas sobre las mismas. La evaluación de las prácticas será individual, y por tanto,deberán haber sido realizadas por los dos miembros de cada grupo. La corrección de lasprácticas tendrá lugar en el laboratorio y se hará delante de cada grupo.

Sólo los alumnos que superen la parte práctica podrán optar a realizar el examen dela parte de teoría. Una vez que un alumno supera la parte práctica, queda liberado de lamisma en las siguientes convocatorias.

En las siguientes tablas se indica: el día de inicio de cada práctica, en el que se explicará(al inicio de cada turno) el contenido de la misma; el día límite de entrega (al finalizarel turno correspondiente); el día de corrección (en las horas correspondientes acada turno).

TurnoPráctica 1

Inicio Entrega CorrecciónLunes 14 Marzo 4 Abril 11 AbrilMartes 15 Marzo 29 Marzo 5 AbrilMiércoles 16 Marzo 30 Marzo 6 AbrilJueves 17 Marzo 31 Marzo 7 Abril

TurnoPráctica 2

Inicio Entrega CorrecciónLunes 11 Abril 25 Abril 2 MayoMartes 5 Abril 19 Abril 26 AbrilMiércoles 6 Abril 20 Abril 27 AbrilJueves 7 Abril 21 Abril 28 Abril

1

2 CAPÍTULO 1. EVALUACIÓN Y CALENDARIO DE PRÁCTICAS

TurnoPráctica 3

Inicio Entrega CorrecciónLunes 2 Mayo 30 Mayo 6 JunioMartes 26 Abril 24 Mayo 31 MayoMiércoles 27 Abril 25 Mayo 1 JunioJueves 28 Abril 26 Mayo 2 Junio

Entrega de prácticas:

Cada grupo soXX deberá dejar, en el directorio /home/clave/labs/so/practicaN/soXX/los ficheros fuentes correspondientes a la prácticaN al finalizar el turno correspondiente adicho grupo, tal y como se indica en las tablas anteriores. Dichos directorios ya están crea-dos (no son subdirectorios dentro de la cuenta de cada usuario), y se bloquearánuna vez finalice el plazo de presentación de cada práctica.

Si se detectan prácticas copiadas, todos los miembros de las parejas involucradas sus-penderán la asignatura.

Capítulo 2

Enunciado de las Prácticas

2.1. Práctica 1

2.1.1. Objetivos

Entender el funcionamiento de las llamadas al sistema relacionadas con la creaciónde procesos (fork, execl, wait). Se recomienda leer la parte del manual relativa aestas llamadas y realizar los programas de ejemplo que se incluyen (ver el capítulo 4del manual). Se recomienda también leer el manual on-line de dichas llamadas alsistema (man fork, man execl, man -a wait (o man 2 wait)).

Implementar un grafo de precedencia sincronizando la ejecución concurrente de va-rios procesos.

2.1.2. Enunciado

(a) Implementar el grafo de precedencia de la figura 2.1 utilizando las llamadas al siste-ma fork y wait (no utilizar waitpid). El grupo de sentencias a ejecutar en cada nododel grafo se simularán mediante la sentencia printf(“cadena”), donde “cadena” es lacadena de caracteres que contiene cada nodo de la figura. La frase deberá apareceren una única línea.

(b) Repetir el apartado anterior utilizando un proceso auxiliar imprime_pantallacuyo código será ejecutado por los procesos hijo mediante la llamada al sistema execl.Dicho proceso deberá imprimir en pantalla, mediante la sentencia printf(“cadena”),la(s) cadena(s) de caracteres que reciba como argumento(s).

Los resultados obtenidos (implementando correctamente la precedencia del grafo de lafigura) en los dos apartados no deben ser los esperados. En el primer apartado se debenobtener palabras repetidas, mientras que en el segundo éstas deben verse en un orden nopermitido por el grafo pero sin repetirse. Ambas situaciones son debidas a cómo funcionanlas llamadas al sistema fork y execl. El objetivo es detectar la causa de estas dos anomalíasy entender su solución.

3

4 CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS

Hola

Buenos tengadias

malos

usted.y Hasta

luego

Lucas

Figura 2.1: Grafo de Precedencia.

2.2. PRÁCTICA 2 5

2.2. Práctica 2

2.2.1. Objetivos

Utilizar los semáforos como una herramienta de sincronización para acceder en ex-clusión mutua a un recurso compartido. Para ello, se proporciona una librería quepermite la utilización de semáforos de una manera sencilla y similar a la explicadaen teoría (ver detalladamente el capítulo 5 del manual).

Utilizar semáforos genéricos para controlar el acceso de N procesos a un recurso.

Utilizar el sistema de ficheros como un recurso compartido entre varios procesos,entendiendo el funcionamiento de las llamadas al sistema fopen, fprintf, fscanf yfclose.

2.2.2. Enunciado

Implementar, mediante la utilización de semáforos el problema clásico de Santa Claus,que se describe como sigue. Santa Claus duerme en su taller del polo norte y sólo puededespertarse en dos circunstancias:

Cuando los 4 renos vuelven de sus vacaciones.

El último reno en llegar debe despertar a Santa Claus. Mientras, los otros 3 renosdeben esperar en un refugio a que llegue el cuarto reno y Santa Claus esté listo paraempezar el reparto de juguetes.

Cuando algún duende tiene dificultades para hacer juguetes.

Para permitir que Santa Claus duerma, los duendes sólo pueden despertarle cuandoson tres los que tienen problemas. Además, cuando tres duendes han ido a plantearsus problemas a Santa Claus, cualquier otro duende que desee visitar a Santa Clausdebe esperar a que éstos regresen.

Si Santa Claus despierta y encuentra tres duendes en la puerta de su taller, juntocon el último reno que vuelve de vacaciones, Santa Claus decide que los duendes puedenesperar hasta después de Navidad, y se va a repartir juguetes.

En la solución se debe proporcionar el código de los tres tipos de procesos involucradossanta, reno y duende; así como el código de dos dos procesos encargados de crear y des-truir los semáforos necesarios para la sincronización: inic_santa y fin_santa. Además,se utilizarán los ficheros “duendes.txt” y “renos.txt” para almacenar la informaciónmínima necesaria para la resolución del problema, teniendo en cuenta que: i) el acceso alfichero “duendes.txt” es en lectura para santa; y en lectura/escritura para los procesosduende (los procesos reno no pueden acceder); ii) el acceso al fichero “renos.txt” es enlectura para santa; y en lectura/escritura para los procesos reno (los procesos duende nopueden acceder).

En la resolución de la práctica se supondrá la existencia de un único proceso santa, unnúmero no determinado de procesos duende y exactamente 4 procesos reno. Cada procesose ejecutará en una ventana diferente. A continuación, se describe el funcionamiento decada uno de los tres tipos de procesos.


Proceso santa (“santa.c”)

El proceso santa debe esperar descansando a que los 4 renos hayan regresado de sus va-caciones o 3 duendes tengan problemas para hacer juguetes. A continuación, dependiendodel caso, o bien se va a repartir juguetes o ayuda a los duendes a resolver sus problemas.Se repite este comportamiento hasta que se seleccione una opción para finalizar el procesosanta. A continuación, se muestran dos ejemplos de ejecución del proceso santa, indicandolos mensajes que se deben mostrar en pantalla.

> santa

Durmiendo .....

Voy a repartir juguetes (pulsa ENTER o 1 para finalizar)

<se pulsa ENTER>

Durmiendo .....

>santa

Durmiendo .....

Ayudo a duende

<se pulsa ENTER>

Ayudo a duende

<se pulsa ENTER>

Ayudo a duende (pulsa ENTER o 1 para finalizar)

<se pulsa ENTER>

Durmiendo .....

Proceso reno (“reno.c”)

Los procesos reno deben esperar en el refugio hasta que el último reno haya regresadode sus vacaciones. Cuando Santa Claus decide ir a repartir juguetes se lleva a los renos;una vez finalizado el trabajo, los renos se van otra vez de vacaciones. Se repite estecomportamiento hasta que se seleccione una opción para finalizar el proceso reno. Acontinuación, se muestran dos ejemplos de ejecución de un proceso reno, indicando losmensajes que se deben mostrar en pantalla.

> reno

Estoy de vacaciones (pulsa ENTER o 1 para finalizar)

<se pulsa ENTER>

Espero en el refugio a los demás renos .....

Voy a repartir juguetes ....


> reno


<se pulsa ENTER>

Voy a repartir juguetes ....


2.2. PRÁCTICA 2 7

Proceso duende (“duende.c”)

Los procesos duende hacen continuamente juguetes hasta que tienen un problema. Enese momento se dirigen al taller de Santa Claus a pedir ayuda. Sin embargo, si ya han idotres duendes a pedir ayuda, el duende con problemas debe esperar a que regresen. Unavez que un duende con problemas ha recibido ayuda, se repite el comportamiento anteriorhasta que se seleccione una opción para finalizar el proceso duende. A continuación, semuestran dos ejemplos de ejecución de un proceso duende, indicando los mensajes que sedeben mostrar en pantalla.

> duende

Haciendo juguetes (pulsa ENTER si tienes problemas o 1 para finalizar)

<se pulsa ENTER>

Voy en busca de ayuda ....

Resuelto el problema


> duende


<se pulsa ENTER>

Voy en busca de ayuda ....

Soy el tercer duende y despierto a Santa Claus

Resuelto el problema



2.3. Práctica 3

2.3.1. Objetivos

Utilizar una herramienta de sincronización de alto nivel como son los monitorescondicionales. Para ello, se proporciona una librería que permite la utilización demonitores de una manera sencilla y similar a la explicada en teoría (ver detallada-mente el capítulo 6 del manual). Además, en el manual se incluyen dos monitoresde ejemplo cuya implementación y prueba se recomienda antes de abordar estapráctica.

Entender las diferencias existentes entre los dos tipos de monitores vistos en teoría,en función del proceso elegido para continuar la ejecución cuando se despierta unproceso suspendido en una variable condition.

2.3.2. Enunciado

En este problema se deberá simular mediante la utilización de un monitor fabrica lagestión de una fabrica en la que existen empleados de dos categorías:

1. Categoría A: son los empleados encargados de la fabricación de cada uno de losproductos. Dado que la fábrica dispone de 2 tipos de productos, un grupo de em-pleados de la categoría A fabrica productos del tipo 1, y otro fabrica productos deltipo 2. Cada empleado fabrica ejemplares del producto correspondiente de unoen uno. Una vez fabricado un ejemplar lo lleva a un almacén con capacidad para Nproductos, donde se almacenan todos los productos de la fábrica (tanto los de tipo1 como los de tipo 2).

Los empleados de categoría A acceden al almacen en orden FIFO. Dicho orden FIFOsólo puede romperse para garantizar que no exista interbloqueo.

2. Categoría B: son los empleados encargados de realizar el control de calidad de losproductos fabricados que han sido depositados en el almacén. Esta tarea se lleva acabo sobre un puesto de trabajo individual para cada empleado, donde el controlde calidad sólo se puede realizar utilizando simultáneamente un producto de tipo1 y uno de tipo 2. El resultado de dicho control de calidad puede ser:

a) Positivo: en ese caso los dos productos pasan a la red de distribución de ventas.

b) Negativo: este resultado se obtiene cuando uno de los dos productos (el de tipo1 o el de tipo 2) no supera el control de calidad, por lo que dicho producto sedesecha. En ese caso, es necesario que dicho empleado retire un nuevo productodel tipo desechado, y realice un nuevo control de calidad.

Observe que, en el caso de que ambos productos fuesen defectuosos, el control decalidad sólo detecta uno de ellos, mientras que el otro será detectado en futuroscontroles —suponga que no es posible que se generen productos defectuosos demanera indefinida.

2.3. PRÁCTICA 3 9

Los empleados de categoría B acceden al almacén en orden FIFO. Dicho orden sólopuede romperse si no es posible realizar ningún control de calidad manteniendo elFIFO, pero sí rompiendo dicho orden FIFO. Es decir, el objetivo es realizar el mayornúmero de controles de calidad posibles.

Además, se tendrán en cuenta las siguientes consideraciones:

1. Se implementará un proceso denominado empA, que se ejecutará con un parámetroen la línea de comandos: empA tipo. El parámetro tipo consistirá en un númeroindicando el tipo de producto producido (1 ó 2). Dicho proceso, una vez depositadoel producto en el almacén, indicará mediante un mensaje por pantalla: i) el númerode elementos de cada tipo en el almacén; y ii) el número de empleados empB queestán esperando por cada tipo de producto —si hay un empB esperando por los dostipos de productos, éste se contabilizará como un empB esperando por el tipo 1, yun empB esperando por el tipo 2.

2. Se implementará un proceso denominado empB que, una vez retirados los dos pro-ductos necesarios para realizar el control de calidad, mostrará un menú en pantallacon dos opciones: “a” Positivo. “b” Negativo. En el caso de seleccionar la opción “b”,se mostrará un nuevo menú en el que se seleccionará el tipo de producto que nosuperó el control de calidad: “1” Tipo 1. “2” Tipo 2. Esta operación se repetirá hastaobtener un control positivo.

Además, antes de mostrar el menú del control de calidad, indicará mediante unmensaje por pantalla: i) el número de elementos de cada tipo en el almacén; ii) elnúmero total de controles de calidad realizados hasta el momento; y iii) el númerode empleados empA que están esperando para introducir cada uno de los dos tiposde productos.

3. Se podrán ejecutar un número indefinido de procesos empA y empB. Cada uno deellos en una ventana diferente.

4. El número máximo de elementos del almacén N será una constante definida en elmonitor.

5. Se implementarán dos procesos encargados de crear y destruir el monitor:crear_fabrica y fin_fabrica.

2.3.3. Ejemplos de ejecución

>emp A 1

accediendo al almacen .....

Estado del almacen despues de introducir el producto:

Tipo 1: 3 elementos

Tipo 2: 0 elementos

EmpB esperando tipo 1: 0



>emp A 2



Tipo 1: 3 elementos

Tipo 2: 1 elementos



>emp A 1



Tipo 1: 4 elementos

Tipo 2: 0 elementos



>empB

accediendo al almacen por los dos productos .....

Estado del almacen despues de retirar los dos productos:

Tipo 1: 2

Tipo 2: 0

EmpA esperando tipo 1: 2


Numero de controles de calidad: 0

Control de Calidad:

a. Positivo

b. Negativo

>b

Producto defectuoso:

1. Tipo 1

2. Tipo 2

>1

accediendo al almacen por un producto de tipo 1 .....

Estado del almacen despues de retirar un producto de tipo 1:

Tipo 1: 1

Tipo 2: 1



Numero de controles de calidad: 3

Control de Calidad:

a. Positivo

b. Negativo

>a

Capítulo 3

Introducción al Sistema Operativo Unix

El sistema operativo UNIX se desarrolló en los laboratorios Bell desde 1969, y se puededefinir como el núcleo (kernel) de un sistema operativo de tiempo compartido, un progra-ma que controla los recursos de una computadora y los asigna entre los usuarios. Permitea los usuarios ejecutar programas, controla los dispositivos periféricos (discos, terminales,impresoras...), y proporciona un sistema de archivos que administra el almacenamiento alargo plazo de información.

Por ser un sistema operativo multiusuario, para iniciar una sesión UNIX es necesarioidentificarse ante el sistema. Cada usuario tiene asignado un nombre de usuario o login yuna palabra de paso o passwd.

3.1. Archivos

El comando ls muestra los nombres (no el contenido) de los archivos existentes en eldirectorio actual.

> ls

file1

file2

>

El comando ls, al igual que la mayoría de los comandos, tiene opciones que puedense utilizadas para alterar su comportamiento. Dichas opciones se teclean a continuacióndel comando y, en general, están compuestas por una letra precedida del carácter -. Porejemplo, ls -t permite obtener un listado de los archivos por orden de antigüedad (time),es decir, según la fecha en la que han sido alterados por última vez, empezando por elmás reciente.

La opción -l (long) permite obtener una información más completa sobre cada uno delos archivos listados (propietario del fichero, protección, etc.)

11

12 CAPÍTULO 3. INTRODUCCIÓN AL SISTEMA OPERATIVO UNIX

El comando cat imprime en pantalla el contenido de todos los archivos referenciadospor sus argumentos. El comando cat no es útil para visualizar ficheros largos, ya que, nose detiene si el fichero ocupa más de una pantalla.

El comando more, que detiene el listado cada vez que se visualiza una pantalla com-pleta, espera a que el usuario solicite la pantalla siguiente:

> more file1

..........

..........

>

<space> Muestra la siguiente pantalla.

<return> Muestra la siguiente linea.

<b> Muestra la pantalla anterior.

<q> Aborta el listado.

Para cambiar un archivo de nombre se utiliza el comando mv; si lo que se quiere escopiar un archivo, se utiliza el comando cp; y para borrarlo el comando rm.

En caso de duda sobre alguno de los comandos o sobre algunas de las funciones enlenguaje C de las librerías del sistema (<stdio.h>, <stdlib.h>, <unistd.h>, etc.), se re-comienda utilizar el manual (comando man). Por ejemplo, para obtener ayuda acerca delcomando cp:

> man cp

Sobre la ayuda mostrada se avanza con las mismas teclas que en el comando more.Como, en general, puede haber más de una entrada en el manual para un mismo comandoo función, se recomienda utilizar la opción -a. De esta manera, se muestran todas lasentradas del manual existentes, pasando de una entrada a otra mediante la tecla q:

> man -a wait

3.1.1. Directorios

El sistema puede distinguir un archivo llamado file1 de otros que tengan el mismo nom-bre. La distinción se realiza agrupando los archivos en directorios, de manera semejantea como se acomodan los libros en estantes de una biblioteca, por lo que los archivos endistintos directorios pueden tener el mismo nombre sin que se produzca ningún conflicto.

Por lo general, cada usuario tiene un directorio personal o directorio de origen, quecontiene únicamente los archivos que le pertenecen. Cuando un usuario inicia una sesiónUNIX, entra en su directorio de origen.

El comando pwd nos indica el directorio actual. Para cambiar de directorio se utilizael comando cd. Para crear y borrar directorios existen los comandos mkdir y rmdir.

3.2. COMPILACIÓN 13

3.1.2. Disquetera

Para acceder a la disquetera se pueden utilizar las mtools. Para ello, basta con te-clear los comandos comunes del MS-DOS con una m delante. Por ejemplo, para listar elcontenido de un disquete: mdir.

Para copiar todos los archivos a un disquete:

mcopy ‘* a:’

.Para cargar todos los archivos de un disquete:

mcopy ‘a:*.* .’

3.2. Compilación

El compilador de C de GNU, denominado gcc, es un programa que llama al preproce-sador de C, a las diversas pasadas de compilación, y al montaje. Un programa ejemplo.cde un sólo módulo puede compilarse y montarse así:

gcc ejemplo.c

Lo cual generará un ejecutable a.out. Sin embargo, normalmente se compila con laopción -o ejecutable que puede ir en cualquier orden:

gcc ejemplo.c -o ejemplogcc -o ejemplo ejemplo.c

De esta manera, el ejecutable se llamará ejemplo. Si un programa consta de variosmódulos, pueden compilarse y montarse todos juntos. Por ejemplo, si ejemplo_bis.ces el módulo principal y lib_1.c y lib_2.c son módulos auxiliares, puede compilarse ymontarse así (de nuevo, el orden es irrelevante):

gcc lib_1.c lib_2.c ejemplo_bis.c -o ejemplo_bis

Sin embargo, a veces interesa compilar por separado los distintos módulos y luegojuntar todos los objetos en un ejecutable. El montaje se evita con la opción -c, que generalos ficheros objeto con extensión .o:

gcc -c ejemplo_bis.cgcc -c lib_1.cgcc -c lib_2.cgcc lib_1.o lib_2.o ejemplo_bis.o -o ejemplo_bis


En el caso de que haya que montar bibliotecas ubicadas en lugares normalizados, perono incluidas automáticamente por el montador, hay que montarlas con la opción -l. Porejemplo, una compilación y montaje utilizando la librería matemática se realizaría delsiguiente modo:

gcc -lm ejemplo.c -o ejemplo

Finalmente, conviene compilar todos los programas con la opción -Wall para que nosmuestre toda la información disponible warnings de la compilación:

gcc -Wall ejemplo.c -o ejemplo

3.3. Depuración

Para poder depurar un programa hay que indicarle al compilador que almacene in-formación simbólica para el depurador. En el compilador gcc hay que compilar con laopción -g:

gcc -g ejemplo.c -o ejemplo

El depurador simbólico en tiempo real permite examinar la ejecución de un progra-ma para descubrir las causas de errores observados en las pruebas formales y para hacerpruebas informales. El depurador básico se llama gdb y se invoca de la siguiente manera:

gdb programa

Para familiarizarse con su uso se dispone de una ayuda que puede obtenerse pulsandoel mensaje help y siguiendo las instrucciones. Todas las órdenes del depurador se puedenabreviar hasta el mínimo que no sea ambiguo. La forma más elemental de usar el depuradores la siguiente:

1. Se lanza el depurador como se indicó anteriormente.

2. Si los ficheros fuentes no están en el mismo directorio que el ejecutable, se informaal depurador dónde están con: dir directorio.

3. Se pone un punto de parada en el main con: br main.

4. Se lanza la ejecución del programa con run seguido de los parámetros del programay las posibles redirecciones de sus entradas y salidas. El programa se parará en elmain mostrando sus parámetros.

5. Se ejecuta el programa paso a paso con n o s, dependiendo de si queremos entraren los procedimientos o no.

3.4. LLAMADAS AL SISTEMA 15

6. Si se pulsa el retorno de carro, se repite la última orden dada. Así no hay que repetirlos n o los s para ir paso a paso.

7. Si el método resulta tedioso, se puede poner un punto de parada en otro sitio conbr, indicando el nombre de la rutina o el número de línea. Se continúa hasta dichopunto con cont.

8. Puede forzarse a que el programa aborte la ejecución con CTRL-C.

9. Puede saberse en qué punto estamos del programa con where.

10. En todo momento se pueden examinar variables o parte de ellas con p expresión,donde la expresión puede ser cualquier expresión válida en C. También se puedenmodificar con set.

11. Podemos movernos por la pila de activaciones de rutinas con up y down.

12. Puede examinarse el texto fuente con l (diez líneas más), l línea o l línea, línea.

13. Puede cambiarse el módulo fuente que estamos examinado con setfile. También pue-de hacerse referencia a líneas de ficheros distintos del actual anteponiendo el nombredel fichero y “:” al número de línea (por ejemplo, br lib_1.c:21 o l lib_2.c:17).

14. Pulse q para finalizar.

Si se desea utilizar un interfaz gráfico para el depurador ejecute /local/bin/gvd.

3.4. LLamadas al sistema

Para ejecutar un comando del sistema operativo desde un programa en C se utiliza lafunción system():

SYNOPSIS

#include <stdlib.h>

int system (const char * string);

DESCRIPCION

system ejecuta el comando que recibe como parámetro como si éste se hubiera tecleadodesde el terminal.

VALORES RETORNADOS


Retorna -1 en caso de error.

EJEMPLO

La siguiente instrucción ejecuta el comando ls y su salida la envía a un fichero llamado“salida_ls”. De esta manera, podríamos abrir dicho fichero y leer desde el programa en C,la salida del comando ejecutado.

system(‘‘ls > salida_ls’’);

Sin embargo, existe un inconveniente: la creación de ficheros temporales como el fi-chero “salida_ls”. Para evitar esto se utilizan pipes, que nos permiten establecer un flujodirecto de información entre dos procesos, sin tener que pasar previamente por un ficherotemporal.

SYNOPSIS

#include <stdio.h>

FILE *popen(const char *command, const char *type);

int pclose(FILE *stream);

DESCRIPCION

popen() ejecuta el comando que recibe como parámetro, al igual que lo hacía system,pero además establece un pipe de comunicación entre el comando ejecutado y el procesoque ha ejecutado el popen(). Dicho pipe se establece igual que un fichero, sobre el que sepueden realizar operaciones de lectura y/o escritura.

VALORES RETORNADOS

Retorna NULL en caso de error, o un descriptor de fichero en caso contrario.

EJEMPLO

A continuación se muestra un ejemplo en el que se obtiene el PID del proceso llamadoinit:

#include <stdio.h>

#include <stdlib.h>

int main() {

3.4. LLAMADAS AL SISTEMA 17

FILE *fich = NULL;

int pid = -1;

if ((fich = popen("ps -ax | grep -v grep | grep \" init \" ", "r"))

== NULL) {

printf("Error al ejecutar el ps\n");

exit(1);

}

fscanf(fich, "%d", &pid);

pclose(fich);

if (pid == -1) printf("No existe el proceso init\n");

else printf("El PID del proceso init es: %d\n", pid);

return(0);

}

Capítulo 4

Gestión de Procesos

4.1. Definición de Proceso

Un programa es una secuencia de instrucciones escrita en un lenguaje de progra-mación. Un proceso es una instancia de ejecución de un programa. Un programa esun concepto estático, mientras que un proceso es un concepto dinámico. En un entornomultiusuario, es posible que varios usuarios ejecuten el mismo programa, obteniendo unproceso distinto por cada ejecución.

4.2. Estados de un Proceso

En un entorno multitarea coexisten varios procesos que se ejecutan de manera entre-lazada (un único procesador). Sin embargo, algunos procesos se encuentran esperandoeventos, por ejemplo esperando a que el usuario pulse una tecla, dicha espera se deberealizar de manera que se perjudique lo menos posible al resto de procesos, con los que secomparte la CPU.

Si se realiza espera activa, cada vez que el sistema operativo le asigne la CPU adicho proceso, éste “mirará” el teclado a ver si se ha pulsado una tecla, y esto lo repetiráhasta que dicho evento se produzca. Durante todo ese tiempo, el proceso está consumiendoinnecesariamente CPU. Para evitar la espera activa, los procesos se suspenden a esperade eventos, de manera que dichos procesos no entren en el reparto de la CPU.

A continuación se enumeran los distintos estados en los que se puede encontrar unproceso:

Preparados (R): Conjunto de procesos que pueden ejecutarse en este momento,es decir, disponen de todos los recursos necesarios para poder ejecutarse, salvo laCPU. El sistema operativo les irá asignando la CPU a cada uno de ellos.

Ejecutando (O): El proceso ocupa actualmente la CPU: Sólo uno de los procesospreparados se estará ejecutando en cada momento (monoprocesador).

19

20 CAPÍTULO 4. GESTIÓN DE PROCESOS

Suspendidos (S): A dichos procesos les falta, además de la CPU, algún recursopara poder ejecutarse, entendiéndose por recurso un dispositivo, un dato, etc. Losprocesos suspendidos están esperando a que ocurra algún evento para poder accederal recurso que necesitan. Estos procesos no entran en el reparto de la CPU, evitandoasí la espera activa. Cuando se produce el evento esperado, dicho proceso pasará aestar preparado.

Parados (T): Son procesos que tampoco entran en el reparto de la CPU, peroque no están suspendidos a la espera de eventos, sino que han sido parados en suejecución. Para salir de dicho estado hay que mandarles continuar, volviendo así aestar preparados.

Zombies (Z): Cuando un proceso finaliza, se lo comunica a su proceso padre (elproceso que lo creó). Si dicho proceso no captura el aviso de su proceso hijo, éstequeda en un estado “zombies”. En dicho estado, el proceso no consume CPU perosigue ocupando recursos en la tabla de procesos (donde se guarda información decada uno de los procesos existentes en el sistema). Un proceso permanece “zombi”hasta que su proceso padre captura su aviso.

EJECUTANDO

SUSPENDIDO

PARADO

ZOMBICOLA DE PROCESOS

PREPARADOS

Figura 4.1: Estados de un Proceso

4.3. Identificación de Procesos

Cada proceso se identifica mediante su PID (identificador de proceso), que es un núme-ro entero (mayor que cero) que el sistema va asignando a cada proceso cuando éste se crea.

El sistema operativo unix proporciona un comando que nos da información relativaa cada uno de los procesos que existen en el sistema. Para obtener todos los procesos

4.4. CREACIÓN DE PROCESOS: FORK() 21

correspondientes a un usuario usr1: ps -aux | grep usr1. Se recomienda ver el manual (manps).

USER: El propietario del proceso.

PID: El identificador del proceso.

% CPU: Porcentaje de CPU consumida.

% MEM: Porcentaje de memoria consumida.

SIZE: Tamaño total del proceso (Kilobytes).

RSS: Kilobytes del programa en memoria. (El resto estará en disco (swapp)).

TTY: Identificador del terminal desde donde se lanzó el proceso.

STAT: Estado del proceso.

START: Hora en la que empezó o la que se lanzó el proceso.

TIME: Tiempo de CPU consumido.

COMMAND: Nombre del proceso.

4.4. Creación de Procesos: fork()

Los procesos pueden tener una estructura jerárquica, de manera que un proceso (pro-ceso padre) puede crear un nuevo proceso (proceso hijo) y así sucesivamente. Para larealización de aplicaciones con varios procesos, el sistema operativo unix proporciona lallamada al sistema1 fork().

SYNOPSIS

#include <sys/types.h>

#include <unistd.h>

int fork(void);

DESCRIPCION

fork() crea un nuevo proceso exactamente igual (mismo código) al proceso que invocala función. Ambos procesos continúan su ejecución tras la llamada al fork().

1Funciones que se pueden invocar desde un programa en C, y que realizan una llamada al sistema

operativo.


VALORES RETORNADOS

En caso de error retorna -1 y no se crea el proceso hijo. En otro caso, retorna valoresdiferentes al proceso padre (el que lo invocó) y al proceso hijo (el proceso creado):

Proceso Padre: Retorna el PID del proceso hijo.

Proceso Hijo: Retorna 0.

EJEMPLO

En el ejemplo que se muestra a continuación, se crea un proceso hijo que imprime enpantalla el PID de su proceso padre, mientras que el proceso padre imprime en pantallasu propio PID y el del proceso hijo que ha creado. Para ello, se utilizan las llamadas alsistema getpid() y getppid(). El proceso padre, antes de finalizar se suspende hasta que elhijo muere, para evitar que éste se quede zombi. Para ello, utiliza la llamada al sistemawait(), que recibe en la variable status el estado en que el proceso hijo finalizó.

#include <stdio.h>


#include <sys/wait.h>

#include <unistd.h>

#include <stdlib.h>

int main() {

int pid = 0, status = 0, pid_hijo_finalizado = 0;

if ((pid = fork()) == -1) {

printf(‘‘Error al crear proceso hijo\n’’);

exit(1);

}

if (pid == 0) { /* Proceso Hijo */

printf(‘‘El PID de mi proceso padre es %d\n’’, getppid());

exit(1);

}

else { /* Proceso Padre */

printf(‘‘Mi PID es el %d y he creado un proceso hijo cuyo pid es %d\n’’,

getpid(), pid);

pid_hijo_finalizado = wait(&status);

printf(‘‘\nEl proceso hijo [pid] = %d, finalizo con el estado %d\n’’,

pid_hijo_finalizado, status);

}

return(0);

}

4.5. EJECUCIÓN DE PROCESOS: EXECL() 23

4.5. Ejecución de Procesos: execl()

Una llamada al sistema que se utiliza normalmente en combinación con el fork() esexecl(), la cual nos permite sustituir la imagen de un proceso por otro.

SYNOPSIS

#include <unistd.h>

int execl( const char *path, const char *arg, ...);

DESCRIPCION

execl() sustituye la imagen del proceso actual por la del proceso cuyo código se indicacomo parámetro. Comprobar que las sentencias posteriores a un execl() no se ejecutan sidicha función ha tenido éxito (ya que se ha sustituido la imagen del proceso). Es decir,después de una llamada a execl() sólo tiene sentido comprobar si se ha producido algúnerror en la llamada.

PARAMETROS

path: Camino completo del programa a ejecutar.

arg: Lista de argumentos a dicho programa.

VALORES RETORNADOS

Retorna -1 si se produce algun error.

EJEMPLO

En el ejemplo que se muestra a continuación, se crea un proceso hijo que ejecuta elprograma cuyo código se encuentra en un fichero llamado “esclavo”. Dicho programa seejecuta con dos parámetros de entrada, el primero se corresponde al nombre que tomaráen la ejecución (argv[0]), en este caso “nombre”; y el segundo es el parámetro “-a”. La listade argumentos termina con NULL. El proceso padre, simplemente espera a que el procesohijo finalice.

#include <stdio.h>


#include <sys/wait.h>

#include <unistd.h>


#include <stdlib.h>

int main() {

int pid = 0, status = 0;

if ((pid = fork()) == -1) {

printf(‘‘Error al crear proceso hijo\n’’);

exit(1);

}

if (pid == 0) { /* Proceso Hijo */

if (execl(‘‘esclavo’’, ‘‘nombre’’, ‘‘-a’’, NULL) == -1) {

printf(‘‘Error al ejecutar execl\n’’);

return;

}

/* Nunca llega aqui, se ha cambiado la imagen del proceso */

}

else { /* Proceso Padre */

pid_hijo_finalizado = wait(&status);

printf(‘‘\nEl proceso hijo [pid] = %d, finalizo con el estado %d\n’’,

pid_hijo_finalizado, status);

}

return(0);

}

A continuación se muestra un posible código del proceso “esclavo”, que simplementeimprime en pantalla la lista de argumentos recibidos:

#include <stdio.h>

int main(int argc, char *argv[]) {

int i = 0;

for (i = 0; i < argc; i++) printf(‘‘\nArgumento [%d]: %s’’, i, argv[i]);

return(0);

}

Capítulo 5

Utilización de Semáforos en elLaboratorio

El sistema operativo UNIX proporciona unos mecanismos de comunicación entreprocesos llamados ipcs. Dichos mecanismos son: memoria compartida, semáforos y pasode mensajes. Para ofrecer una interfaz de acceso a los semáforos similar a la explicada enlas clases teóricas, se proporciona una librería de funciones en C que encapsula el manejode los ipcs del sistema operativo. Dicha librería de funciones se encuentra en el fichero/opt/ipcms/lib/libipcms.a, y su fichero de cabecera en: /opt/ipcms/include/cipcms.h.

El fichero cipcms.h contiene la declaración de las funciones de manejo de semáforos. Serecomienda leer detenidamente la declaración de las funciones: sem_crear(), sem_capturar(),sem_wait(), sem_signal y sem_destruir() (la función sem_ver() sólo se podrá utilizar, entareas de depuración, para mostrar el valor interno de la variable asociada al semáforo).Cada semáforo se crea con una clave1, de manera que sólo los procesos que conozcan dichaclave puedan acceder al semáforo. Existe, por tanto, un proceso que crea el semáforo yque puede acceder a él a partir del identificador del semáforo retornado, tal y como semuestra a continuación:

#include <cipcms.h>

int main() {

semaforo_t s;

s = sem_crear(1234, 1, 0); /* crea un semaforo binario de paso */

/* con la clave de acceso 1234 y retorna */

/* el descriptor del semaforo creado */

.........................

sem_wait(s);

.........................

sem_signal(s);

1Las claves utilizadas en el laboratorio serán enteros mayores que 1000.

25

26 CAPÍTULO 5. UTILIZACIÓN DE SEMÁFOROS EN EL LABORATORIO

.........................

sem_destruir(s);

return(0);

}

Si algún otro proceso quiere utilizar el semáforo s, deberá obtener su descriptor. Apartir de ese momento, puede interaccionar con el semáforo exactamente igual que elproceso que lo creó. Una vez destruido el semáforo, ningún proceso podrá acceder a él.

#include <cipcms.h>

int main() {

semaforo_t s;

s = sem_capturar(1234); /* retorna el descriptor del semaforo */

/* que se creo con la clave 1234 */

.........................

sem_wait(s);

.........................

sem_signal(s);

.........................

return(0);

}

Para compilar un programa que utilice la librería libipcms.a, es necesario indicarle alcompilador la localización de dicha librería y la de su fichero de cabecera2:

gcc -Wall -I /opt/ipcms/include/ - L /opt/ipcms/lib/ programa.c -lipcms -o programa

Además, es necesario ejecutar un proceso encargado de gestionar los mecanismos decomunicación de bajo nivel que utiliza dicha librería. Para ello basta con ejecutar elprograma: /opt/ipcms/bin/gestoripcms. Dicho proceso debe ser ejecutado una sola vez aliniciarse la sesión en el laboratorio. Al finalizar dicha sesión, debe finalizarse su ejecución.Para ello se proporciona el programa: /opt/ipcms/bin/matagestoripcms.

Si se produce algún error en la ejecución de los programas desarrollados en el laborato-rio, y estos se abortan anormalmente sin destruir antes los semáforos creados, es necesarioabortar también el proceso gestoripcms y ejecutarlo de nuevo. En ese caso, y dependien-do de cómo se abortó el programa que utiliza la librería, puede ser necesario abortar laejecución del proceso gestoripcms mediante el comando kill pid. En ese caso, es necesarioeliminar también las ipcs que estaba utilizando el proceso gestor. Para ello, existen loscomandos: ipcs (similar a ps), e ipcrm (similar a kill) (se recomienda ver el manual (man)

2Ver la sección 3.2.

27

de cada uno de estos comandos. A partir del comando ipcs se obtienen los identificado-res de los ipcs activos, y con el comando ipcrm [sem id] [shm id] [msg id] se eliminan losipcs correspondientes a semáforos (sem), memoria compartida (shm) y colas de mensajes(msg).

Finalmente, se recomienda comprobar todos los posibles errores producidos en las lla-madas a las funciones de manejo de semáforos. En la mayoría de los casos, éstas retornanun valor negativo en caso de error. (Ver fichero /opt/ipcms/include/cipcms.h).

Nota Importante: Al abandonar el laboratorio es imprescindible que se eliminen to-dos los procesos e ipcs creados. En caso contrario, el siguiente grupo no podrá ejecutar elproceso gestoripcms, debiendo reiniciar el ordenador para poder empezar a trabajar. Paraevitar esta situación, antes de abandonar el laboratorio se deberán seguir los siguientespasos:

1. Ejecutar el proceso matagestoripcms.

2. Comprobar que no quedan procesos gestores en ejecución:

>ps -aux | grep gestor

3. Si quedase algún proceso gestor, debe ser eliminado con el comando Kill pid.

4. Comprobar que no quedan ipcs activas:

>ipcs

5. Si quedase alguna ipc, debe ser eliminada con el comando ipcrm.

28 CAPÍTULO 5. UTILIZACIÓN DE SEMÁFOROS EN EL LABORATORIO

Capítulo 6

Utilización de monitores en ellaboratorio

El sistema operativo unix no proporciona mecanismos de sincronización de alto nivelcomo monitores. En el laboratorio se dispone de una implementación software de moni-tores en la librería libcipcms. Para crear el código correspondiente a un monitor genéricodenominado monitor_ejemplo, se deberán seguir los siguientes pasos (sin añadir líneas enblanco ni comentarios):

1. Crear un fichero monitor_ejemplo.mon que contenga la declaración del tipo de moni-tor, las variables condition, los procedimientos ENTRY, un procedimiento de inicioy un procedimiento de finalización, según la siguiente sintaxis:

tipo: 1 (continúa el proceso que señala), ó 2 (continúa el proceso señalizado).condicionales: nombre de las variables de tipo condition, separadas por comas, sinningún carácter al final de la línea. Si la declaración de dichas variables ocupa másde una línea, no deben separarse éstas con un retorno de carro, sino que se escribirántodas seguidas.publicos: nombre de los procedimientos de entrada al monitor. Siguen las mismasnormas que el caso anteriorinicio: nombre de la función que se ejecuta al iniciar el monitor.fin: nombre de la función que se ejecuta al finalizar el monitor. Es necesario queexista, aunque no haga nada.

A partir de esta cabecera, se continua como si fuera un programa C normal. En estecaso, se escribirá el código C de cada uno de los procedimientos del monitor:

tipo: 1

condicionales: lleno, vacio

publicos: procedimiento_1, procedimiento_3, procedimiento_4, procedim

iento_5,

inicio: inicio

fin: fin

29

30 CAPÍTULO 6. UTILIZACIÓN DE MONITORES EN EL LABORATORIO

#include <stdio.h>

int procedimiento_1()

{

}

void procedimiento_2() /* no es ENTRY */

{

}


{

}


{

}


{

}

void inicio()

{

}

void fin()

{

}

En la implementación de la librería que se va a utilizar en el laboratorio, todos losprocedimientos de tipo ENTRY deben retornar un valor entero, y no pueden recibirningún parámetro.

2. A partir de dicho fichero, crear un fichero en C mediante el programa:

/opt/ipcms/bin/mongenint.pl monitor_ejemplo.mon > monitor_ejemplo.c.

3. Compile dicho programa con la librería lipcmsint y la librería del sistema lpthread:

gcc -Wall -I /opt/ipcms/include/ -L /opt/ipcms/lib/ monitor_ejemplo.c-lipcmsint -lpthread -o monitor_ejemplo

El ejecutable creado (monitor_ejemplo) no debe ejecutarse.

4. Crear un programa que cree el monitor:

#include <cipcms.h>

#include <stdio.h>

31

int main () {

if (mon_crear(2000, "monitor_ejemplo") < (monitor_t) 0)

printf("No se puedo lanzar el monitor.\n");

else printf("Monitor lanzado.\n");

return(0);

}

5. Crear un programa para finalizar su ejecución:

#include <stdio.h>

#include <cipcms.h>

int main() {

if (mon_destruir(mon_capturar(2000)) < 0)

printf("error al destruir\n");

else printf("monitor destruido\n");

return(0);

}

6. Para utilizar dicho monitor desde un programa en C, declarar una variable de tipomonitor_t, capturar su descriptor a partir de la clave con la que se creó, e invocara los procedimientos del monitor con la función.

int monitorint(monitor_t, char *)

#include <stdio.h>

#include <cipcms.h>

int main() {

monitor_t mi_monitor;

int n = 0;

mi_monitor = mon_capturar(2000);

........

........

n = monitorint(mi_monitor, "procedimiento_1");

return(0);

}

Estos programa se compilan con la librería ipcms, al igual que los programas queutilizan semáforos y necesitan la ejecución previa del proceso gestoripcms.


7. Para utilizar las variables de tipo condition declaradas en la cabecera existen lasfunciones:

condm_wait(variable), condm_signal(variable) y condm_empty(variable).

6.1. Monitor ejemplo

A continuación, se muestra un monitor de ejemplo que implementa la funcionalidadde un semáforo entero. El ejemplo consta de 4 ficheros: ej_mon.mon correspondienteal monitor, un proceso ej_proc que utiliza dicho monitor y dos procesos para iniciar yfinalizar el monitor: ej_inic.c y ej_fin.c.

::::::::::::::

ej_mon.mon

::::::::::::::

tipo: 1

condicionales: cola_sem

publicos:mi_sem_wait, mi_sem_signal

inicio: mi_inic_sem

fin: mi_fin_sem

/*************************** FIN CABECERA ******************************/

#define N 4 /* valor maximo del semaforo */

int n; /* variable interna del semaforo */

int mi_sem_wait() {

if (n == 0)

condm_wait(cola_sem);

else

n--;

return(0);

}

int mi_sem_signal() {

if (! condm_empty(cola_sem))

condm_signal(cola_sem);

else {

if (n == N) return(1); /* error */

n++;

}

return(0);

}

6.1. MONITOR EJEMPLO 33

void mi_inic_sem()

{

n = N; /* inicialmente el semaforo esta abierto */

}

void mi_fin_sem()

{

return;

}

::::::::::::::

ej_inic.c

::::::::::::::

#include <cipcms.h>

#include <stdio.h>

int main() {

if (mon_crear(2004, "ej_mon") < ((monitor_t) 0))

printf("No se pudo lanzar el monitor\n");

else

printf("Monitor lanzado correctamente\n");

return(0);

}

::::::::::::::

ej_fin.c

::::::::::::::

#include <cipcms.h>

#include <stdio.h>

int main() {


printf("No se pudo destruir el monitor\n");

else

printf("Monitor finalizado\n");

return(0);

}


::::::::::::::

ej_proc.c

::::::::::::::

#include <cipcms.h>

#include <stdio.h>

int main() {

int resultado = 0;

monitor_t mon_sem;

if ((mon_sem = mon_capturar(2004)) < (monitor_t) 0) {

printf("No se pudo capturar el monitor\n");

exit(-1);

}

printf("\nElija una opcion\n1. Wait\n2. Signal\n3.Fin del proceso\n> ");

do {

switch (getchar()) {

case ’1’:

printf("Intentando acceder al recurso...\n");

resultado = monitorint(mon_sem, "mi_sem_wait");

if (resultado < 0) {

printf("Error interno en el monitor\n");

return(-1);

}

else printf("Recurso accedido\n");

printf("\nElija una opcion\n1. Wait\n2. Signal\n3.Fin del

proceso\n> ");

break;

case ’2’:

resultado = monitorint(mon_sem, "mi_sem_signal");

if (resultado < 0) {

printf("Error interno en el monitor\n");

return(-1);

}

else {

if (resultado == 1) printf("Demasiados signals.\n");

else printf("Fin acceso recurso\n");

}

printf("\nElija una opcion\n1. Wait\n2. Signal\n3.Fin del

proceso\n> ");

break;

case ’3’:

return (0);

}

6.1. MONITOR EJEMPLO 35

} while (1);

return(0);

}


6.2. Monitores con paso de parámetros

Para utilizar monitores cuyas funciones ENTRY puedan recibir parámetros, es ne-cesario definir dichos parámetros como punteros a void. A continuación, se describe unejemplo:

1. Fichero buffer.mon:

tipo: 1

condicionales: vacio, lleno

publicos: producir, consumir

inicio: iniciar

fin: finalizar

#include <stdio.h>

#include <stdlib.h>

void *producir(void *);

void *consumir(void *);

void iniciar(void);

void finalizar(void);

#define N 4

int buffer[N], ptr_prod, ptr_cons, num_datos;

void iniciar(void) {

ptr_prod = 0;

ptr_cons = 0;

num_datos = 0;

buffer[0]=0;

buffer[1]=0;

buffer[2]=0;

buffer[3]=0;

}

void *producir(void *dato)

{

if (num_datos == N) condm_wait(lleno);

buffer[ptr_prod] = *((int *) dato);

ptr_prod = (ptr_prod + 1) % N;

num_datos++;

condm_signal(vacio);

return(NULL);

}

6.2. MONITORES CON PASO DE PARÁMETROS 37

void *consumir(void *nada) {

int *mi_dato = NULL;

if ((mi_dato = malloc(sizeof(int))) == NULL) {

printf(‘‘Error en malloc\n’’);

exit(-1);

}

if (num_datos == 0) condm_wait(vacio);

*mi_dato = buffer[ptr_cons];

ptr_cons = (ptr_cons + 1) % N;

num_datos--;

condm_signal(lleno);

return((void *) mi_dato);

}

void finalizar(void)

{

return;

}

2. A partir de dicho fichero, crear un fichero en C mediante el programa:

/opt/ipcms/bin/mongen.pl buffer.mon > buffer.c.

3. Compile dicho programa con la librería lipcms y la librería del sistema lpthread:

gcc -Wall -I /opt/ipcms/include/ -L /opt/ipcms/lib/ buffer.c -lipcms-lpthread -o buffer

El ejecutable creado (buffer) no debe ejecutarse.

4. Crear un programa que cree el monitor:

#include <cipcms.h>

#include <stdio.h>

int main () {

if (mon_crear(1234, "buffer") < (monitor_t) 0)

printf("No se puedo lanzar el monitor.\n");

else printf("Monitor lanzado.\n");

return(0);


}

5. Crear un programa para finalizar su ejecución:

#include <stdio.h>

#include <cipcms.h>

int main() {


printf("error al destruir\n");

else printf("monitor destruido\n");

return(0);

}

6. Para utilizar dicho monitor desde un programa en C, declarar una variable de tipomonitor_t, capturar su descriptor a partir de la clave con la que se creó, e invocara los procedimientos del monitor con la función.

int monitor(monitor_t, char *, size_t, size_t, void*)

***********

productor.c

***********

#include <stdio.h>

#include <stdlib.h>

#include <cipcms.h>

int main() {

monitor_t m;

int dato=3;

if ((m = mon_capturar(1234))<0)

{

printf("Error al capturar el monitor\n");

exit(-1);

}

printf("Producir elemento:");

fscanf(stdin,"%d", &dato);

monitor(m, "producir", sizeof(int), 0, (void *)&dato);

return(0);

}

************

6.2. MONITORES CON PASO DE PARÁMETROS 39

consumidor.c

************

#include <stdio.h>

#include <stdlib.h>

#include <cipcms.h>

int main() {

monitor_t m;

int *dato;

if ((m = mon_capturar(1234))<0)

{

printf("Error al capturar el monitor\n");

exit(-1);

}

dato = (int *) (monitor(m,"consumir", 0, sizeof(int), NULL));

printf("Consumido %d\n",*dato);

free(dato);

return(0);

}

Estos programa se compilan con la librería ipcms, al igual que los programas queutilizan semáforos y necesitan la ejecución previa del proceso gestoripcms.

manual de prÆcticas de sistemas...

Documents