Manual de Prácticas de Sistemas Operativos

Manual de Prácticas de Sistemas
Operativos
Curso 2010-2011
Índice general
1. Evaluación y Calendario de Prácticas
1.1. Evaluación de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Calendario de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Entrega de prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2
2. Enunciado de las Prácticas
2.1. Práctica 1 . . . . . . . . .
2.1.1. Objetivos . . . . .
2.1.2. Enunciado . . . . .
2.2. Práctica 2 . . . . . . . . .
2.2.1. Objetivos . . . . .
2.2.2. Enunciado . . . . .
Proceso escritor . .
Proceso lector . . .
2.3. Práctica 3 . . . . . . . . .
2.3.1. Objetivos . . . . .
2.3.2. Enunciado . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Utilización y Gestión de Procesos en el
3.1. Definición de Proceso . . . . . . . . . .
3.2. Estados de un Proceso . . . . . . . . .
3.3. Identificación de Procesos . . . . . . .
3.4. Creación de Procesos: fork() . . . . . .
3.5. Ejecución de Procesos: execl() . . . . .
3.6. Compilación . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
5
5
5
5
6
7
7
7
Laboratorio
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
11
13
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áctica
obligatoria (práctica 3) en la fecha indicada, que dicha práctica funcione y responder
correctamente a algunas preguntas sobre la misma.
Opcionalmente, el alumno puede realizar las prácticas voluntarias puntuables, entregándolas siempre en los plazos de entrega fijados. En el caso de que el alumno supere
la práctica obligatoria (práctica 3), se evaluarán la prácticas voluntarias (prácticas 1
y 2). En caso de una evaluación positiva de ambas, el alumno obtendrá un punto que
será sumado a la puntuación del examen teórico siempre y cuando apruebe dicho
examen teórico.
La evaluación será individual, y por tanto, las prácticas deberán haber sido realizadas
por los dos miembros de cada grupo. Si se detectan prácticas copiadas, todos los miembros
de las parejas involucradas suspenderán la asignatura.
Para aprobar la parte teórica de la asignatura es necesario haber superado
la parte práctica. Es decir, sólo los alumnos que superen la parte práctica (al menos
la práctica 3) podrán realizar el examen de la parte de teoría. Una vez que un alumno
supera la parte práctica, queda liberado de la misma en las siguientes convocatorias. Las
prácticas voluntarias puntuables sólo tienen validez en la convocatoria de Junio del curso
académico en el que se realizan.
1
CAPÍTULO 1. EVALUACIÓN Y CALENDARIO DE PRÁCTICAS
2
1.2.
Calendario de prácticas
La corrección de las prácticas tendrá lugar en el laboratorio, durante el horario de
prácticas del grupo, siendo imprescindible la presencia de todos los miembros del grupo
de prácticas.
En la siguiente tabla se indica: el día de comienzo de cada práctica, el día límite de
entrega de cada práctica (a las 14:00), y el día de corrección de prácticas (en las horas
correspondientes a cada turno) para cada uno de los turnos de laboratorio.
Turno
Lunes
Martes
Miércoles
Práctica 1
Inicio
Entrega
28 Febrero 18 Marzo
1 Marzo
18 Marzo
2 Marzo
18 Marzo
Práctica 2
Práctica 3
Inicio
Entrega Inicio Entrega
21 Marzo 8 Abril 4 Abril 5 Mayo
22 Marzo 8 Abril 5 Abril 5 Mayo
23 Marzo 8 Abril 6 Abril 5 Mayo
Corrección
9 Mayo
10 Mayo
11 Mayo
Además de en el presente documento, se describirá cada una de las prácticas el día de
comienzo de cada una de ellas, según se indica en el calendario anterior. Dicha explicación
tendrá 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 asignatura, http://gssi.det.uvigo.es/˜ jgd/SO/SO.htm, está disponible el software necesario
para utilizar el gestor de semáforos y monitores instalados en el laboratorio. Cada grupo
de laboratorio, no más de 2 personas, dispondrá de una cuenta de usuario soXX en el
servidor de laboratorios docentes. Las cuentas de usuario se pueden solicitar a los profesores 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 dicha
práctica. Dichos directorios ya están creados (no son subdirectorios dentro de la
cuenta de cada usuario), y se bloquearán una vez finalice el plazo de presentación de
cada 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ón
de procesos (fork, execl, wait). Se recomienda leer la parte del manual relativa a
estas llamadas y realizar los programas de ejemplo que se incluyen (ver el capítulo 3
del manual). Se recomienda también leer el manual on-line de dichas llamadas al
sistema (man fork, man execl, man -a wait (o man 2 wait)).
Implementar un grafo de precedencia sincronizando la ejecución concurrente de varios procesos.
2.1.2.
Enunciado
(a) Implementar el grafo de precedencia de la figura 2.1 utilizando las llamadas al sistema fork y wait (no utilizar waitpid). El grupo de sentencias a ejecutar en cada nodo
del grafo se simularán mediante la sentencia printf(“cadena”), donde “cadena” es la
cadena de caracteres que contiene cada nodo de la figura. La frase deberá aparecer
en una única línea.
(b) Repetir el apartado anterior utilizando un proceso auxiliar imprime_pantalla
cuyo 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 la
figura) en los dos apartados no deben ser los esperados. En el primer apartado se deben
obtener palabras repetidas, mientras que en el segundo éstas deben verse en un orden no
permitido por el grafo pero sin repetirse. Ambas situaciones son debidas a cómo funcionan
las llamadas al sistema fork y execl. El objetivo es detectar la causa de estas dos anomalías
y entender su solución.
3
CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS
4
Hola
Buenos
dias
tenga
y
usted.
Hasta
luego
malos
Lucas
Figura 2.1: Grafo de Precedencia.
2.2. PRÁCTICA 2
2.2.
Práctica 2
2.2.1.
Objetivos
5
Utilizar los semáforos como una herramienta de sincronización para acceder en exclusión mutua a un recurso compartido. Para ello, se proporciona una librería que
permite la utilización de semáforos de una manera sencilla y similar a la explicada
en 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 y
fclose.
2.2.2.
Enunciado
Implementar, mediante la utilización de semáforos, el problema clásico de los lectoresescritores. 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 debe
dar soporte a la existencia de varios procesos escritores y varios procesos lectores, teniendo
en 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ún
proceso 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 (cuando
el papel queda libre, siempre se da paso primero a un proceso escritor antes que a
un proceso lector).
Se podrá utilizar un fichero auxiliar (llamado “aux.txt”) en el que se incluyan las
variables compartidas por los procesos escritores y lectores. Se valorará la utilización
de la información mínima compartida.
A continuación se describe el funcionamiento de cada uno de los dos tipos de procesos. Se deberán implementar, además, dos procesos encargados de crear y destruir los
semáforos necesarios, así como inicializar los ficheros: inic_papel y fin_papel.
Proceso escritor
Presenta en pantalla dos opciones:
1. Escribir
2. Finalizar
CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS
6
Cuando se seleccione la opción Escribir, el proceso deberá mostrar en pantalla la palabra
en el fichero “papel.txt”; esperar a que el usuario introduzca una nueva palabra; actualizar
el fichero; y volver al menú anterior. Este comportamiento se repite hasta que se selecciona
la opción Finalizar. Además, el proceso escritor mostrará en pantalla mensajes aclaratorios
similares 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 primer
carácter de la palabra en el fichero “papel.txt”; cada vez que se pulse la tecla <ENTER> se
mostrará 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 aclaratorios
similares 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
2.3.
Práctica 3
2.3.1.
Objetivos
7
Utilizar una herramienta de sincronización de alto nivel como son los monitores
condicionales. Para ello, se proporciona una librería que permite la utilización de
monitores de una manera sencilla y similar a la explicada en teoría (ver detalladamente el capítulo 5 del manual). Además, en el manual se incluyen dos monitores
de ejemplo cuya implementación y prueba se recomienda antes de abordar esta
prá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 un
proceso suspendido en una variable condition.
2.3.2.
Enunciado
En este problema se deberá simular mediante la utilización de un monitor BUFFER
la 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 elementos de tipo t1 y productores que producen únicamente elementos de tipo t2 . Cada
proceso productor intenta introducir un número 1 ≤ n ≤ N de elementos del tipo
correspondiente. Dichos procesos esperan sin introducir ningún elemento hasta
que 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 elementos de tipo t2 . Cada proceso consumidor intenta consumir un único elemento del
tipo correspondiente, esperando hasta que pueda consumir el elemento deseado.
Los procesos productores no conocen el tipo de los elementos que introducen en el
buffer.
Cada proceso productor recibirá como parámetro el tipo correspondiente (1 o 2) y
el número de elementos a producir.
Para que un proceso consumidor pueda averiguar el tipo de los elementos que hay en
el buffer es necesario que dichos elementos sean extraídos. Si un proceso consumidor
extrae un elemento del buffer y éste no es de su tipo debe introducir de nuevo dicho
elemento en el buffer e intentarlo con el siguiente elemento. Si no le sirve ningún
elemento 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.
CAPÍTULO 2. ENUNCIADO DE LAS PRÁCTICAS
8
• extraer_elemento(): extrae el primer elemento del buffer indicando el tipo del
mismo.
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 proceso
productor no puede ser adelantado por otros procesos productores.
Los procesos consumidores acceden al buffer en orden FIFO. Sin embargo, un proceso
consumidor de tipo t1 (t2 ) puede ser adelantado por procesos consumidores de tipo
t2 (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_buffer
y 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 el
Laboratorio
3.1.
Definición de Proceso
Un programa es una secuencia de instrucciones escrita en un lenguaje de programación. Un proceso es una instancia de ejecución de un programa. Un programa es
un concepto estático, mientras que un proceso es un concepto dinámico. En un entorno
multiusuario, es posible que varios usuarios ejecuten el mismo programa, obteniendo un
proceso distinto por cada ejecución.
3.2.
Estados de un Proceso
En un entorno multitarea coexisten varios procesos que se ejecutan de manera entrelazada (un único procesador). Sin embargo, algunos procesos se encuentran esperando
eventos, por ejemplo esperando a que el usuario pulse una tecla, dicha espera se debe
realizar de manera que se perjudique lo menos posible al resto de procesos, con los que se
comparte la CPU.
Si se realiza espera activa, cada vez que el sistema operativo le asigne la CPU a
dicho 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á consumiendo
innecesariamente CPU. Para evitar la espera activa, los procesos se suspenden a espera
de 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 un
proceso:
Preparados (R): Conjunto de procesos que pueden ejecutarse en este momento,
es decir, disponen de todos los recursos necesarios para poder ejecutarse, salvo la
CPU. 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 procesos
preparados se estará ejecutando en cada momento (monoprocesador).
Suspendidos (S): A dichos procesos les falta, además de la CPU, algún recurso
para poder ejecutarse, entendiéndose por recurso un dispositivo, un dato, etc. Los
procesos suspendidos están esperando a que ocurra algún evento para poder acceder
al recurso que necesitan. Estos procesos no entran en el reparto de la CPU, evitando
así la espera activa. Cuando se produce el evento esperado, dicho proceso pasará a
estar preparado.
Parados (T): Son procesos que tampoco entran en el reparto de la CPU, pero
que no están suspendidos a la espera de eventos, sino que han sido parados en su
ejecución. Para salir de dicho estado hay que mandarles continuar, volviendo así a
estar preparados.
Zombies (Z): Cuando un proceso finaliza, se lo comunica a su proceso padre (el
proceso que lo creó). Si dicho proceso no captura el aviso de su proceso hijo, éste
queda en un estado “zombies”. En dicho estado, el proceso no consume CPU pero
sigue ocupando recursos en la tabla de procesos (donde se guarda información de
cada uno de los procesos existentes en el sistema). Un proceso permanece “zombi”
hasta que su proceso padre captura su aviso.
PARADO
COLA DE PROCESOS
PREPARADOS
EJECUTANDO
ZOMBI
SUSPENDIDO
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úmero 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 relativa
a cada uno de los procesos que existen en el sistema. Para obtener todos los procesos
correspondientes a un usuario usr1: ps -aux | grep usr1. Se recomienda ver el manual (man
ps).
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 (proceso padre) puede crear un nuevo proceso (proceso hijo) y así sucesivamente. Para la
realización de aplicaciones con varios procesos, el sistema operativo unix proporciona la
llamada 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 invoca
la función. Ambos procesos continúan su ejecución tras la llamada al fork().
1
Funciones 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 valores
diferentes 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 en
pantalla el PID de su proceso padre, mientras que el proceso padre imprime en pantalla
su propio PID y el del proceso hijo que ha creado. Para ello, se utilizan las llamadas al
sistema getpid() y getppid(). El proceso padre, antes de finalizar se suspende hasta que el
hijo muere, para evitar que éste se quede zombi. Para ello, utiliza la llamada al sistema
wait(), que recibe en la variable status el estado en que el proceso hijo finalizó.
#include
#include
#include
#include
#include
<stdio.h>
<sys/types.h>
<sys/wait.h>
<unistd.h>
<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()
3.5.
13
Ejecución de Procesos: execl()
Una llamada al sistema que se utiliza normalmente en combinación con el fork() es
execl(), 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 indica
como parámetro. Comprobar que las sentencias posteriores a un execl() no se ejecutan si
dicha 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ún
error 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 el
programa cuyo código se encuentra en un fichero llamado “esclavo”. Dicho programa se
ejecuta 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 lista
de argumentos termina con NULL. El proceso padre, simplemente espera a que el proceso
hijo finalice.
#include
#include
#include
#include
<stdio.h>
<sys/types.h>
<sys/wait.h>
<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 simplemente
imprime 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 preprocesador de C, a las diversas pasadas de compilación, y al montaje. Un programa ejemplo.c
de 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 la
opción -o ejecutable que puede ir en cualquier orden:
gcc ejemplo.c -o ejemplo
gcc -o ejemplo ejemplo.c
De esta manera, el ejecutable se llamará ejemplo. Si un programa consta de varios
módulos, pueden compilarse y montarse todos juntos. Por ejemplo, si ejemplo_bis.c
es el módulo principal y lib_1.c y lib_2.c son módulos auxiliares, puede compilarse y
montarse 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 luego
juntar todos los objetos en un ejecutable. El montaje se evita con la opción -c, que genera
los ficheros objeto con extensión .o:
gcc
gcc
gcc
gcc
-c ejemplo_bis.c
-c lib_1.c
-c lib_2.c
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, pero
no incluidas automáticamente por el montador, hay que montarlas con la opción -l. Por
ejemplo, una compilación y montaje utilizando la librería matemática se realizaría del
siguiente modo:
gcc -lm ejemplo.c -o ejemplo
Finalmente, conviene compilar todos los programas con la opción -Wall para que nos
muestre 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 el
Laboratorio
El sistema operativo UNIX proporciona unos mecanismos de comunicación entre
procesos llamados ipcs. Dichos mecanismos son: memoria compartida, semáforos y paso
de mensajes. Para ofrecer una interfaz de acceso a los semáforos similar a la explicada en
las clases teóricas, se proporciona una librería de funciones en C que encapsula el manejo
de 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. Se
recomienda 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, en
tareas 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 dicha
clave puedan acceder al semáforo. Existe, por tanto, un proceso que crea el semáforo y
que puede acceder a él a partir del identificador del semáforo retornado, tal y como se
muestra 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);
1
Las claves utilizadas en el laboratorio serán enteros mayores que 1000.
17
CAPÍTULO 4. UTILIZACIÓN DE SEMÁFOROS EN EL LABORATORIO
18
.........................
sem_destruir(s);
return(0);
}
Si algún otro proceso quiere utilizar el semáforo s, deberá obtener su descriptor. A
partir de ese momento, puede interaccionar con el semáforo exactamente igual que el
proceso 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 al
compilador 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 de
comunicación de bajo nivel que utiliza dicha librería. Para ello basta con ejecutar el
programa: /opt/ipcms/bin/gestoripcms. Dicho proceso debe ser ejecutado una sola vez al
iniciarse 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 laboratorio, y estos se abortan anormalmente sin destruir antes los semáforos creados, es necesario
abortar también el proceso gestoripcms y ejecutarlo de nuevo. En ese caso, y dependiendo de cómo se abortó el programa que utiliza la librería, puede ser necesario abortar la
ejecución del proceso gestoripcms mediante el comando kill pid. En ese caso, es necesario
eliminar también las ipcs que estaba utilizando el proceso gestor. Para ello, existen los
comandos: ipcs (similar a ps), e ipcrm (similar a kill) (se recomienda ver el manual (man)
2
Ver la sección 3.6.
19
de cada uno de estos comandos. A partir del comando ipcs se obtienen los identificadores de los ipcs activos, y con el comando ipcrm [sem id] [shm id] [msg id] se eliminan los
ipcs correspondientes a semáforos (sem), memoria compartida (shm) y colas de mensajes
(msg).
Finalmente, se recomienda comprobar todos los posibles errores producidos en las llamadas a las funciones de manejo de semáforos. En la mayoría de los casos, éstas retornan
un valor negativo en caso de error. (Ver fichero /opt/ipcms/include/cipcms.h).
Nota Importante: Al abandonar el laboratorio es imprescindible que se eliminen todos los procesos e ipcs creados. En caso contrario, el siguiente grupo no podrá ejecutar el
proceso gestoripcms, debiendo reiniciar el ordenador para poder empezar a trabajar. Para
evitar esta situación, antes de abandonar el laboratorio se deberán seguir los siguientes
pasos:
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 el
laboratorio
El sistema operativo unix no proporciona mecanismos de sincronización de alto nivel
como monitores. En el laboratorio se dispone de una implementación software de monitores en la librería libcipcms. Para crear el código correspondiente a un monitor genérico
denominado monitor_ejemplo, se deberán seguir los siguientes pasos (sin añadir líneas en
blanco ni comentarios):
1. Crear un fichero monitor_ejemplo.mon que contenga la declaración del tipo de monitor, las variables condition, los procedimientos ENTRY, un procedimiento de inicio
y 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, sin
ningún carácter al final de la línea. Si la declaración de dichas variables ocupa más
de una línea, no deben separarse éstas con un retorno de carro, sino que se escribirán
todas seguidas.
publicos: nombre de los procedimientos de entrada al monitor. Siguen las mismas
normas que el caso anterior
inicio: 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 que
exista, aunque no haga nada.
A partir de esta cabecera, se continua como si fuera un programa C normal. En este
caso, 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
CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
22
#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 utilizar
monitores cuyas funciones ENT RY puedan recibir parámetros, es necesario definir
dichos parámetros como punteros a void. A continuación, se describe un ejemplo
para 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
void
void
void
*producir(void *);
*consumir(void *);
iniciar(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 las
funciones:
condm_wait(variable), condm_signal(variable) y condm_empty(variable).
CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
24
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 tipo
monitor_t, capturar su descriptor a partir de la clave con la que se creó, e invocar
a 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);
CAPÍTULO 5. UTILIZACIÓN DE MONITORES EN EL LABORATORIO
26
}
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 que
utilizan semáforos y necesitan la ejecución previa del proceso gestoripcms.