Embed Size (px)
Citation preview
Manual de Prácticas de SistemasOperativos
Curso 2010-2011
Índice general
1. Evaluación y Calendario de Prácticas 11.1. Evaluación de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Calendario de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Entrega de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Enunciado de las Prácticas 32.1. Práctica 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Práctica 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Proceso escritor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Proceso lector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Práctica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Utilización y Gestión de Procesos en el Laboratorio 93.1. Definición de Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2. Estados de un Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. Identificación de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4. Creación de Procesos: fork() . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5. Ejecución de Procesos: execl() . . . . . . . . . . . . . . . . . . . . . . . . . 133.6. Compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Utilización de Semáforos en el Laboratorio 17
5. Utilización de monitores en el laboratorio 21
i
ii ÍNDICE GENERAL
Capítulo 1
Evaluación y Calendario de Prácticas
El calendario de prácticas de la asignatura recoge un total de 3 prácticas.
Práctica 1: Práctica voluntaria puntuable.
Práctica 2: Práctica voluntaria puntuable.
Práctica 3: Práctica OBLIGATORIA.
1.1. Evaluación de prácticas
Para aprobar la parte práctica de la asignatura, es necesario entregar la prácticaobligatoria (práctica 3) en la fecha indicada, que dicha práctica funcione y respondercorrectamente a algunas preguntas sobre la misma.
Opcionalmente, el alumno puede realizar las prácticas voluntarias puntuables, en-tregándolas siempre en los plazos de entrega fijados. En el caso de que el alumno superela práctica obligatoria (práctica 3), se evaluarán la prácticas voluntarias (prácticas 1y 2). En caso de una evaluación positiva de ambas, el alumno obtendrá un punto queserá sumado a la puntuación del examen teórico siempre y cuando apruebe dichoexamen teórico.
La evaluación será individual, y por tanto, las prácticas deberán haber sido realizadaspor los dos miembros de cada grupo. Si se detectan prácticas copiadas, todos los miembrosde las parejas involucradas suspenderán la asignatura.
Para aprobar la parte teórica de la asignatura es necesario haber superadola parte práctica. Es decir, sólo los alumnos que superen la parte práctica (al menosla práctica 3) podrán realizar el examen de la parte de teoría. Una vez que un alumnosupera la parte práctica, queda liberado de la misma en las siguientes convocatorias. Lasprácticas voluntarias puntuables sólo tienen validez en la convocatoria de Junio del cursoacadémico en el que se realizan.
1
2 CAPÍTULO 1. EVALUACIÓN Y CALENDARIO DE PRÁCTICAS
1.2. Calendario de prácticas
La corrección de las prácticas tendrá lugar en el laboratorio, durante el horario deprácticas del grupo, siendo imprescindible la presencia de todos los miembros del grupode prácticas.
En la siguiente tabla se indica: el día de comienzo de cada práctica, el día límite deentrega de cada práctica (a las 14:00), y el día de corrección de prácticas (en las horascorrespondientes a cada turno) para cada uno de los turnos de laboratorio.
TurnoPráctica 1 Práctica 2 Práctica 3
CorrecciónInicio Entrega Inicio Entrega Inicio EntregaLunes 28 Febrero 18 Marzo 21 Marzo 8 Abril 4 Abril 5 Mayo 9 MayoMartes 1 Marzo 18 Marzo 22 Marzo 8 Abril 5 Abril 5 Mayo 10 MayoMiércoles 2 Marzo 18 Marzo 23 Marzo 8 Abril 6 Abril 5 Mayo 11 Mayo
Además de en el presente documento, se describirá cada una de las prácticas el día decomienzo de cada una de ellas, según se indica en el calendario anterior. Dicha explicacióntendrá lugar al inicio de cada turno en el laboratorio LA4 de la Torre A.
1.3. Entrega de prácticas
No es necesario realizar las prácticas en el laboratorio. En la página Web de la asignatu-ra, http://gssi.det.uvigo.es/˜ jgd/SO/SO.htm, está disponible el software necesariopara utilizar el gestor de semáforos y monitores instalados en el laboratorio. Cada grupode laboratorio, no más de 2 personas, dispondrá de una cuenta de usuario soXX en elservidor de laboratorios docentes. Las cuentas de usuario se pueden solicitar a los profeso-res responsables a partir de la fecha de inicio de las prácticas (semana del 28 de Febrero).Se recomienda leer el manual antes de abordar el desarrollo de las mismas.
Cada grupo soXX deberá dejar, en el directorio /home/clave/labs/so/practicaN/soXX/los ficheros fuentes correspondientes a la prácticaN antes de la fecha de entrega de dichapráctica. Dichos directorios ya están creados (no son subdirectorios dentro de lacuenta de cada usuario), y se bloquearán una vez finalice el plazo de presentación decada práctica.
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 3del 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 4 del manual).
Utilizar semáforos genéricos para controlar el acceso de N procesos a un recurso.
Utilizar semáforos de paso para sincronizar procesos.
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 los lectores-escritores. Se utilizará un fichero (llamado papel.txt) con una única palabra de texto(máximo 20 caracteres) seguida de un carácter de final de línea. En la solución se debedar soporte a la existencia de varios procesos escritores y varios procesos lectores, teniendoen cuenta que:
Sólo se permitirá leer a cuatro lectores simultáneamente.
Si en el momento en que un proceso escritor intenta acceder al papel existe algúnproceso lector leyendo, el proceso escritor se demorará hasta que el papel quede libre,o hasta que finalicen la lectura cuatro procesos lectores.
Los procesos escritores son prioritarios con respecto a los procesos lectores (cuandoel papel queda libre, siempre se da paso primero a un proceso escritor antes que aun proceso lector).
Se podrá utilizar un fichero auxiliar (llamado “aux.txt”) en el que se incluyan lasvariables compartidas por los procesos escritores y lectores. Se valorará la utilizaciónde la información mínima compartida.
A continuación se describe el funcionamiento de cada uno de los dos tipos de pro-cesos. Se deberán implementar, además, dos procesos encargados de crear y destruir lossemáforos necesarios, así como inicializar los ficheros: inic_papel y fin_papel.
Proceso escritor
Presenta en pantalla dos opciones:
1. Escribir
2. Finalizar
6 CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS
Cuando se seleccione la opción Escribir, el proceso deberá mostrar en pantalla la palabraen el fichero “papel.txt” ; esperar a que el usuario introduzca una nueva palabra; actualizarel fichero; y volver al menú anterior. Este comportamiento se repite hasta que se seleccionala opción Finalizar. Además, el proceso escritor mostrará en pantalla mensajes aclaratoriossimilares a los que se indican a continuación (en el ejemplo el fichero contiene la palabra“antiguo” y el escritor introduce la palabra “nuevo”):
Intentando acceder al fichero ‘‘papel.txt’’...
Acceso OK
palabra actual: antiguo
palabra nueva: nuevo <ENTER>
Fichero actualizado
Proceso lector
Presenta en pantalla dos opciones:
1. Leer
2. Finalizar
Cuando se seleccione la opción Leer, el proceso deberá mostrar en pantalla el primercarácter de la palabra en el fichero “papel.txt” ; cada vez que se pulse la tecla <ENTER> semostrará la siguiente letra de dicha palabra; y una vez mostrada la última letra, se volveráal menú inicial. Además, el proceso lector mostrará en pantalla mensajes aclaratoriossimilares a los que se indican a continuación (en el ejemplo el fichero contiene la palabra“antiguo”):
Intentando acceder al fichero ‘‘papel.txt’’...
Acceso OK
a <se pulsa ENTER>
n <se pulsa ENTER>
t <se pulsa ENTER>
i <se pulsa ENTER>
g <se pulsa ENTER>
u <se pulsa ENTER>
o <se pulsa ENTER>
Fin de la lectura
2.3. PRÁCTICA 3 7
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 5 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 BUFFERla gestión de un buffer de N posiciones con las siguientes características:
En el buffer coexisten dos tipos de elementos t1 y t2.
Existen 2 tipos de procesos productores: productores que producen únicamente ele-mentos de tipo t1 y productores que producen únicamente elementos de tipo t2. Cadaproceso productor intenta introducir un número 1 ≤ n ≤ N de elementos del tipocorrespondiente. Dichos procesos esperan sin introducir ningún elemento hastaque puedan introducir la totalidad de elementos deseados.
Igualmente, existen 2 tipos de procesos consumidores: consumidores que consumenúnicamente elementos de tipo t1 y consumidores que consumen únicamente elemen-tos de tipo t2. Cada proceso consumidor intenta consumir un único elemento deltipo correspondiente, esperando hasta que pueda consumir el elemento deseado.
Los procesos productores no conocen el tipo de los elementos que introducen en elbuffer.
Cada proceso productor recibirá como parámetro el tipo correspondiente (1 o 2) yel número de elementos a producir.
Para que un proceso consumidor pueda averiguar el tipo de los elementos que hay enel buffer es necesario que dichos elementos sean extraídos. Si un proceso consumidorextrae un elemento del buffer y éste no es de su tipo debe introducir de nuevo dichoelemento en el buffer e intentarlo con el siguiente elemento. Si no le sirve ningúnelemento deberá esperar hasta que pueda consumir el elemento deseado.
Suponga que existen las siguientes funciones internas del monitor:
• introducir_elemento(): introduce un elemento al final del buffer.
8 CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS
• extraer_elemento(): extrae el primer elemento del buffer indicando el tipo delmismo.
Cada proceso consumidor recibirá como parámetro el tipo correspondiente (1 o 2).
Los procesos productores acceden al buffer en orden FIFO. Es decir, un procesoproductor no puede ser adelantado por otros procesos productores.
Los procesos consumidores acceden al buffer en orden FIFO. Sin embargo, un procesoconsumidor de tipo t1 (t2) puede ser adelantado por procesos consumidores de tipot2 (t1) cuando en el buffer no hay elementos del tipo t1 (t2).
Se implementarán dos procesos encargados de crear y destruir el monitor: crear_buffery fin_buffer.
Ejemplos de ejecución:
> productor 1 4
He producido 4 elementos.
Esperando a poder introducir los elementos en el buffer...
Elementos introducidos. Hay 12 elementos en total.
> consumidor 2
Esperando a retirar un elemento de tipo 2...
Elemento de tipo 2 retirado y consumido. Quedan 11 elementos en total.
Capítulo 3
Utilización y Gestión de Procesos en elLaboratorio
3.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.
3.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.
9
10CAPÍTULO 3. UTILIZACIÓN Y GESTIÓN DE PROCESOS EN EL LABORATORIO
Ejecutando (O): El proceso ocupa actualmente la CPU: Sólo uno de los procesospreparados se estará ejecutando en cada momento (monoprocesador).
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 3.1: Estados de un Proceso
3.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.
3.4. CREACIÓN DE PROCESOS: FORK() 11
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 procesoscorrespondientes 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.
3.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.
12CAPÍTULO 3. UTILIZACIÓN Y GESTIÓN DE PROCESOS EN EL LABORATORIO
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/types.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);
}
3.5. EJECUCIÓN DE PROCESOS: EXECL() 13
3.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/types.h>
#include <sys/wait.h>
#include <unistd.h>
14CAPÍTULO 3. UTILIZACIÓN Y GESTIÓN DE PROCESOS EN EL LABORATORIO
#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);
}
3.6. 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í:
3.6. COMPILACIÓN 15
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
16CAPÍTULO 3. UTILIZACIÓN Y GESTIÓN DE PROCESOS EN EL LABORATORIO
Capítulo 4
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.
17
18 CAPÍTULO 4. 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.6.
19
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.
20 CAPÍTULO 4. UTILIZACIÓN DE SEMÁFOROS EN EL LABORATORIO
Capítulo 5
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
21
22 CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
#include <stdio.h>
void *procedimiento_1(void *)
{
}
int procedimiento_2() /* no es ENTRY */
{
}
void *procedimiento_3(void *)
{
}
void *procedimiento_4(void *)
{
}
void *procedimiento_5(void *)
{
}
void inicio()
{
}
void fin()
{
}
En la implementación de la librería que se va a utilizar en el laboratorio, para utilizarmonitores cuyas funciones ENTRY puedan recibir parámetros, es necesario definirdichos parámetros como punteros a void. A continuación, se describe un ejemplopara la resolución de un problema productor-consumidor. 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);
23
#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);
}
void *consumir(void *nada) {
static int mi_dato = 0;
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;
}
Para utilizar las variables de tipo condition declaradas en la cabecera existen lasfunciones:
condm_wait(variable), condm_signal(variable) y condm_empty(variable).
24 CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
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() {
if (mon_destruir(mon_capturar(1234)) < 0)
printf("error al destruir\n");
else printf("monitor destruido\n");
return(0);
}
25
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.
void * monitor(monitor_t, char * nb_entry, size_t tam_entrada, size_t tam_salida, void * par_entrada)
***********
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);
}
************
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);
26 CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
}
dato = (int *) (monitor(m,"consumir", 0, sizeof(int), NULL));
printf("Consumido %d\n",*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.
