Sistemas Operacionales

Semestre 8
Fascculo No. 5

Tabla de contenido
Problemas clsicos de procesos
El problema de la cena de los filsofos
El problema de lectores escritores
El problema del peluquero dormido
Seales y excepciones
Seales
Servicios POSIX WIN32
Resumen
Bibliografa recomendada
Prrafo nexo
Autoevaluacin formativa

Problemas clsicos de procesos

Para ver cmo trabajan los planificadores de procesos, nos devolvemos un

poco para mirar los problemas que generalmente se encuentran en un sistema
operativo. De la literatura sobre problemas clsicos, tomaremos 3 ejemplos que
nos ampliarn la visin y nos ilustrarn para desarrollar soluciones ptimas.

Indicadores de logro

Al terminar el estudio del presente fascculo, el estudiante:

Ampla su visin sobre los problemas de procesos ms comunes.

Identifica el manejo de errores y excepciones en la programacin de un

sistema operativo y las aplicaciones sobre ste.

Explica los servicios bsicos que exporta posix y win32, para el manejo de
errores.

El problema de la cena de los filsofos

En 1965, Dijkstra plante y resolvi un problema de sincronizacin al que llam

problema de la cena de los filsofos. Desde entonces, quienquiera que haya
inventado una primitiva de sincronizacin ms se ha sentido obligado a
demostrar lo maravillosa que es mostrando la forma tan elegante en que
resuelve el problema de la cena de los filsofos. El problema tiene un
planteamiento muy sencillo. Cinco filsofos estn sentados alrededor de una
mesa circular. Cada filsofo tiene ante s un plato de espagueti. El espagueti es
tan resbaloso que un filsofo necesita dos palitos para comerlo. Entre cada par
de platos hay un palito. La disposicin de la mesa se muestra en la figura 5.1.

Figura 5.1 Hora de comer en el departamento de filosofa.

Fuente: S. Tanenbaum Word Dhull. Sistemas Operativos. Diseo e implementacin. 2da.
edicin, pg. 76.

La vida de un filsofo consiste en periodos alternantes de comer y pensar.

(Estos es una abstraccin). Cuando un filsofo siente hambre, trata de adquirir
sus palitos izquierdo y derecho, uno a la vez, en cualquier orden. Si logra
adquirir los dos palitos, comer durante un momento, luego pondr los palitos
en la mesa y seguir pensando.

La pregunta es la siguiente: Podremos escribir un programa para cada filsofo

que haga lo que se supone que debe hacer y nunca se entrampe?

Las siguientes lneas de cdigo muestran la solucin obvia. El procedimiento

take_stick (tomar palito) espera hasta que el palito especificado est disponible
y luego se apodera de l. Desafortunadamente, la solucin obvia est
equivocada. Supongamos que todos los filsofos toman su palito izquierdo
simultneamente. Ninguno podr tomar su tenedor derecho, y tendremos un
bloqueo mutuo.

Podramos modificar el programa de modo que, despus de tomar su palito

izquierdo, el programa verifique si el tenedor derecho est disponible. Si no es

as, el filsofo soltar su palito izquierdo, esperar cierto tiempo, y repetir el

proceso. Esta propuesta tambin fracasa aunque por una razn distinta. Con
un poco de mala suerte, todos los filsofos podran iniciar el algoritmo
simultneamente. Tomar el tenedor izquierdo, esperar, tomar su tenedor
izquierdo otra vez que manera simultnea, y as eternamente. Una situacin
as, en la que todos los programas continan ejecutndose de manera
indefinida pero no logra avanzar, se denomina inanicin.

Ahora podemos pensar: si los filsofos esperan un tiempo aleatorio en lugar

del mismo tiempo despus de fracasar en su intento por disponer del tenedor
derecho, la posibilidad de que sus acciones continuaran coordinadas durante
una hora es excesivamente pequea. Esto es cierto, pero en algunas
aplicaciones preferiramos una solucin que siempre funcione y que no tenga
posibilidad de fallar debido a una serie improbable de nmeros aleatorios.

Una mejora de este cdigo que no est sujeta a bloqueo ni inanicin, consiste
en proteger las cinco instrucciones que siguen a la llamada think con un
semforo binario. Antes de comenzar a conseguir tenedores, un filsofo
ejecutara DOWN con mutex. Despus de dejar los tenedores en la mesa,
ejecutara UP con mutex. Desde un punto de vista terico, esta solucin es
adecuada. En la prctica, tiene un problema de rendimiento: solo un filsofo
puede estar comiendo en un instante dado. Si hay cinco tenedores disponibles,
deberamos estar en condiciones de permitir que dos filsofos comieran al
mismo tiempo.

Actividad 5.1

Escriba en seudo-cdigo (similar al de la funcin), una solucin donde por lo

menos dos filsofos coman al mismo tiempo.

El problema de lectores escritores

El problema de la cena de los filsofos es til para modelar procesos que

compiten por tener acceso exclusivo a un nmero limitado de recursos, como
dispositivos de E/S. Otro problema famoso es el de los lectores escritores, que
modela a una base de datos. Imaginemos, por ejemplo, un sistema de
reservaciones de una lnea area, con muchos procesos competidores que
desean leerlo y escribir en l. Es aceptable tener mltiples procesos leyendo la
base de datos al mismo tiempo, pero si un proceso est actualizando
(escribiendo en) la base de datos, ningn otro podr tener acceso a ella, ni
siquiera los lectores. La pregunta es, cmo programamos a los lectores
escritores?

La solucin que presentamos aqu contiene implcitamente una sutil decisin

que vale la pena comentar. Supongamos que mientras un lector est usando la
base de datos, llega otro lector. Puesto que tener dos lectores al mismo tiempo
no est prohibido, se admite al segundo lector. Tambin puede admitirse un
tercer lector y lectores subsecuentes si llegan.

Supongamos ahora que llega un escritor. El escritor no puede ser admitido en

la base de datos, pues requiere acceso exclusivo, de modo que el escritor
queda suspendido. Ms adelante, llegan lectores adicionales. En tanto haya al
menos un lector activo, se admitirn lectores subsecuentes. A consecuencia de
esta estrategia, en tanto haya un suministro constante de lectores, entrarn tan
pronto como lleguen. El escritor se mantendr suspendido hasta que no haya
ningn lector presente. Si llega un lector, digamos cada 2 segundos, y cada
lector tarda 5 segundos en efectuar su trabajo, el escritor nunca entrar.

Para evitar esta situacin, el programa podra incluir una pequea modificacin,
cuando llega un lector y un escritor est esperando, el lector queda suspendido
detrs del escritor en lugar de ser admitido inmediatamente, As, un escritor
tiene que esperar hasta que terminen los lectores que estaban activos cuando
lleg, pero no a que terminen los lectores que llegaron despus de l. La

desventaja de esa solucin es que logra menor concurrencia y por tanto un

menor rendimiento.

Actividad 5.1

Escriba una solucin en seudo-cdigo, donde muestre el funcionamiento de N

lectores y escritores a un recurso determinado.

El problema del peluquero dormido

Otro problema de IPC clsico ocurre en una peluquera. Esta peluquera tiene
un peluquero, una silla del peluquero y n sillas donde pueden sentarse los
clientes que esperan, si los hay. Si no hay clientes presentes, el peluquero se
sienta en la silla y se duerme, como se ilustra en la figura 5.2. Cuando llega un
cliente, tiene que despertar al peluquero dormido. Si llegan clientes adicionales
mientras el peluquero est cortndole el pelo a un cliente, se sientan (si hay
sillas vacas) o bien salen del establecimiento (si todas las sillas estn
ocupadas). El problema consiste en programar al peluquero y sus clientes sin
entrar en condiciones de competencia.

Figura 5.2 Peluquero dormido

Fuente: S. Tanenbaum Word Dhull. Sistemas Operativos. Diseo e implementacin. 2da.
edicin, pg. 81.

Una solucin utiliza tres semforos: customers, que cuenta a los clientes en
espera (excluyendo al que est siendo atendido que no est esperando),
barbers, el nmero de peluqueros que estn ociosos, esperando clientes (0 o
1), y mutex, que se usa para la exclusin mutua. Tambin necesitamos una
variable, waiting (esperando), que tambin cuenta los clientes que estn
esperando, y en esencia es una copia de customers. Necesitamos esta variable
porque no es posible leer el valor actual de un semforo. En esta solucin, un
cliente que entra en la peluquera debe contar el nmero de clientes que
esperan. Si este nmero es menor que el nmero de sillas, se queda; si no se
va.

Esta solucin se muestra en el cdigo siguiente:

# define CHAIRS 5
typedef int semaphore;
semaphore customer = 0;
semaphore barber = 0;
semaphore mutex = 1;
int wating = 0;

void barber (void)

{
while (true){
down(customers);
down(mutex);
waiting = waiting 1;
up(barbers);
up(mutex);
cut_hair();
}
}

void customer(void)
{
down(mutex);
if ( waiting < CHAIRS)
{
waiting = waiting + 1;
up(customers);
up(mutex);
down(barbers);
get_haircut();
}
else
{
up(mutex);

}
}

Cuando el peluquero llega a trabajar en las maanas, ejecuta el procedimiento

barber (peluquero) que lo obliga a bloquearse en espera de customers hasta
que llegue alguien. Luego se duerme como se muestra en la figura 5.2.

Cuando un cliente llega, ejecuta customer (cliente), cuya primera instruccin es

adquirir mutex para entrar en una regin crtica. Si otro cliente llega poco
tiempo despus, no podr hacer nada hasta que el primero haya liberado
mutex. A continuacin, el cliente verifica si el nmero de clientes en espera es
menor que el nmero de sillas. Si no es as, el cliente libera mutex y se sale sin
su corte de pelo.

Una vez terminado el corte de pelo, el cliente sale del

procedimiento y de la peluquera.

Observacin
A diferencia de los ejemplos anteriores, no hay un ciclo para el cliente porque
cada uno slo recibe un corte de pelo. El peluquero s opera un ciclo, tratando
de atender al siguiente cliente. Si hay uno presente, el peluquero realiza otro
corte de pelo, si no, se duerme.

Actividad 5.3

Escriba frente al cdigo de problema anterior, de forma normal, qu representa

cada una de las instrucciones.

Seales y excepciones

Cuando un sistema operativo desea notificar a un proceso la ocurrencia de un

determinado evento o error, recurre a dos tipos de mecanismos: seales y

excepciones. Las primeras se utilizan en POSIX y las segundas en Windows

NT.

Seales

Las seales tienen, frente al proceso, el mismo comportamiento que las

interrupciones frente al procesador, por lo que se puede decir que una seal es
una interrupcin al proceso.

El proceso que recibe una seal se comporta como muestra la figura 5.3, de la
siguiente forma:

El proceso detiene su ejecucin en la instruccin de mquina que est

ejecutando.

Bifurca al ejecutar una rutina de tratamiento de la seal, cuyo cdigo ha de

formar parte del propio proceso.

Una vez ejecutada la rutina de tratamiento, sigue la ejecucin del proceso

en la instruccin en el que fue interrumpido.

Figura 5.3 Recepcin de una seal por parte de un proceso.

Fuente: S. Tanenbaum Word Dhull. Sistemas Operativos. Diseo e implementacin. 2da.
edicin, pg. 110.

Observacin
El origen de una seal puede ser un proceso o el sistema operativo.

Actividad 5.2

Investigue cmo realizar el sistema operativo y los programas para realizar

comunicacin mediante seales.

Excepciones

Una excepcin es un evento que ocurre durante la ejecucin de un programa y

que requiere la ejecucin de un fragmento de cdigo situado fuera del flujo
normal de ejecucin.

Las excepciones son generadas por el hardware o el software. Ejemplos de

excepciones hardware incluyen la divisin por cero o la ejecucin de
instrucciones ilegales. Las excepciones software incluyen aquellas detectadas
y notificadas por el sistema operativo o el propio proceso. Cuando ocurre una
excepcin, tanto en hardware como en software, el control es transferido al
sistema operativo que ejecuta la rutina de tratamiento de excepcin
correspondiente. Esta rutina crea un registro de excepcin que contiene
informacin sobre la excepcin generada. Si existe un manejador para la
excepcin generada, el sistema operativo transfiere el control a dicho
manejador, en caso contrario aborta la ejecucin del proceso.

El manejo de excepciones necesita el soporte del lenguaje de programacin

para que el programador pueda especificar el manejador a ejecutar cuando se
produzca una excepcin. Un esquema habitual es el que se presenta a
continuacin.

Try
Bloque donde puede producirse una excepcion
Except
Bloque se ejecutar en momento de ejecutarse una excepcin en el bloque
anterior.
End;

Actividad 5.4

Escriba un documento con 5 llamadas al sistema para seales y 5 llamadas al

sistema para excepciones.

Resumen

Los problemas clsicos o IPC son aquellas ilustraciones que se presentan en el

momento de realizar programacin con un sistema operativo; el problema de la
cena de los filsofos y el problema del lector escritor, son las principales
herramientas para que el estudiante se gue sobre cmo resolver situaciones
similares.

Las seales y las excepciones son un complemento para que las aplicaciones
realizadas por los programadores tengan un tratamiento adecuado en el
momento de ocurrir.

Bibliografa recomendada

Silbertchatz y P. Galvn. Operating System Concepts. Addison Wesley, 5a

edicin, 1999.

M.J. Bach. The Desing of the Unix Operating System. Prentice-Hall, 1986.

P. de Miguel. Fundamentos de los computadores. Ed. Paraninfo, 1998

J. Carrete, P. Anasagasti, F. Garca y F. Prez. Sistemas Operativos. Una

Visin Aplicada. McGraw Hill, 2001.

S. Tanenbaum, Word Dhull. Sistemas Operativos. Diseo e Imprementacin

2da. Edicin.

K. Reichard y D. Burnette. Comunication and Networking Fundamentals. MISS

press, 1994.

Nexo

El siguiente fascculo presenta una breve forma de conocer las herramientas y

conceptos bsicos de UNIX. Se presentan algunas de las diferencias de los
servicios que presta POSIX y los servicios que presta WIN32. Adems se
estudiar cmo realizar un pequeo programa sin necesidad de utilizar un
compilador.

Autoevaluacin formativa

1. Presente una solucin para cada uno de los problemas de IPC.

2. Realice un programa para cada una de las seales y excepciones,

explicado su funcionalidad.