Pontificia Universidad Catolica de Chile Escuela de Ingenier a Departamento de Ciencia de la Computacion

IIC 2332 Sistemas Operativos

Proyecto 1a Parte Sincronizacin de Threads en Nachos o

Mircoles 24 de marzo de 2004 e Fecha de entrega: Viernes 16 de abril de 2004 Ayudant Lunes 5 de abril de 2004 a: El proyecto del curso se desarrollar en grupos de dos personas. Para conformar los grupos se debe a enviar un mail a cruz@ing.puc.cl, indicando los nombres y los correos electrnicos de ambos integrantes ; o a continuacin se le responder con los datos de su cuenta. o a Cada alumno contar con una cuenta en el computador nachos.ing.puc.cl, que funciona bajo el sistema a operativo Linux Fedora Core 1. En el sitio web del proyecto, http://nachos.ing.puc.cl/ se encuentran las instrucciones para instalar Nachos 3.4 en la cuenta suministrada. Tambin se encontrar all informacin e a o util para el desarrollo de cada etapa del proyecto.

Objetivos
Familiarizarse con el sistema operativo Nachos y su sistema de procesos livianos, o hebras (threads), el cual se encuentra inicialmente incompleto. Observar los efectos de la falta de sincronizacin cuando se trabaja con programas concurrentes. o Implementar algunas primitivas de sincronizacin para Nachos. o Resolver de manera correcta un problema de sincronizacin utilizando las primitivas de sincronizacin o o y los threads de Nachos.

Pruebas preliminares
Luego de instalar Nachos en su directorio base (HOME ), construya el ejecutable utilizando make en el directorio code. El ejecutable de Nachos que nos interesa para esta etapa quedar en el subdirectorio threads. a Para probar que todo est bien, ejecute ./nachos desde el subdirectorio threads. Esto ejecutar una prueba a a simple de Nachos. Examinando threads/main.cc se puede ver que, luego de realizar algunas inicializaciones y lecturas de parmetros, lo que se ejecuta es la funcin ThreadTest(), la cual se encuentra dentro del archivo a o threads/threadtest.cc. Esta funcin es un ejemplo simple de un programa concurrente. En este caso o hay dos threads independientes ejecutndose al mismo tiempo, y accediendo a los mismos datos. a

Parte 1. Threads de Nachos.

El primer objetivo del proyecto es comprender el funcionamiento de las operaciones primitivas de procesos livianos empleadas en este programa. Para ello se harn algunos experimentos que ayuden a comprender lo a que ocurre realmente cuando se tienen mltiples hebras durante la ejecucin. Para entender el camino de u o ejecucin, siga el cdigo del ejemplo simple suministrado. Rerase en la pgina web a las notas sobre o o e a Seguimiento y Depuracin de Programas en Nachos, donde encontrar algunas sugerencias sobre cmo o a o hacer esto. Para comprender el funcionamiento del objeto thread se deben estudiar los archivos threads/thread.h y threads/thread.cc, donde se encuentra la denicin de la clase. En particular, observe lo que ocurre o cuando un thread llama a la funcin Thread::Yield() para abandonar la CPU y dar el turno a otro. Este o proceso de ejecutar otro thread es llevado a cabo por el objeto scheduler, cuya denicin se encuentra en o el archivo threads/scheduler.h y threads/scheduler.cc, utilizando una pol tica FCFS. Observe que en este programa los threads llaman a la funcin Thread::Yield() en cada ciclo de la funcin o o SimpleThread, con lo cual entregan la CPU voluntariamente al thread siguiente. Este comportamiento es determin stico. En un sistema operativo t pico, en lugar de abandonar la CPU voluntariamente, los threads son sacados y puestos nuevamente en ejecucin por el planicador (scheduler), de acuerdo a alguna pol o tica de planicacin expropiativa (preemptive scheduling). o En Nachos se puede simular un ambiente en que los threads son sacados de ejecucin sin previo aviso o utilizando el parmetro (ag) -rs semilla, produciendo ejecuciones con entremezclas pseudoaleatorias. a A modo de ejemplo, observe las diferencias ejecutando ./nachos -rs semilla, para distintos valores de semilla. Si las diferencias de ejecucin no son notorias fcilmente, pruebe aumentando el nmero de threads o a u o el nmero de iteraciones que realiza cada uno. u

Parte 2. Threads sin sincronizacin. o

Construya un programa sencillo del tipo Productor/Consumidor, con T threads productores y T threads consumidores, que trabajan sobre un buer esttico de tamao M , inicialmente vac Cada productor debe a n o. introducir N enteros aleatorios en el buer, y cada consumidor debe retirar N enteros del mismo. Realice una implementacin utilizando un arreglo esttico de tamao M . Dado que no estamos utilizando o a n primitivas de sincronizacin, su implementacin debe aprovechar la pol o o tica FCFS de Nachos, y las instrucciones Thread::Yield() para lograr el comportamiento esperado tanto del buer como de los productores y consumidores. Incluya una funcin que permita imprimir el contenido del arreglo. La implementacin debe o o ser entregada en un archivo similar a threadtest.cc, de nombre thread-array.cc. El comportamiento esperado es que los productores no puedan ingresar elementos si el buer est lleno, a y que los consumidores no puedan retirar elementos si el buer est vac Adems, cada entero que es a o. a ingresado debe ser retirado exactamente una vez por algn consumidor, y el buer debe quedar vac al nal u o de la ejecucin. o Realice una segunda implementacin del problema Productor/Consumidor, pero en esta ocasin utilice la o o clase List de Nachos, detallada en los archivos threads/list.h y threads/list.cc. Esta clase implementa una lista dinmica, por lo que esta vez el parmetro M es innecesario. Una vez ms, sin utilizar primitivas a a a de sincronizacin, organice la ejecucin de los threads de forma de conseguir un comportamiento esperado. o o Esta implementacin debe ser entregada en un archivo de nombre thread-list.cc. o El siguiente paso es identicar algunos casos de comportamiento incorrecto que se podr producir en an sus programas si se utilizara, por ejemplo, la opcin -rs de Nachos, para producir cambios de contexto aleao torios. Debe identicar dos casos de prueba sucientemente distintos para cada una de las implementaciones (thread-array.cc y thread-list.cc), bajo los cuales la introduccin de instrucciones Thread::Yield() o provocar comportamientos incorrectos, y ejemplicarlos. Para ello agregue un cuarto parmetro, E a la a a l nea de comandos, en cuyo caso el valor 0 representar un comportamiento normal, y los valores 1 y 2 reprea sentarn casos de prueba que muestren comportamientos incorrectos. Estos casos deben estar incorporados a dentro de los archivos thread-array.cc y thread-list.cc.

En todos los casos, los valores de T , M , N y E deben ser le dos por l nea de comandos. De esta forma, la ejecucin de ./nachos -T 5 -M 12 -N 4 -E 0 debe producir una ejecucin con 5 productores y 5 cono o sumidores que insertan o retiran 4 elementos cada uno, que trabajan sobre un buer de tamao 12, y con n un comportamiento correcto. Dato. Dentro de la evaluacin de esta parte, se probar el funcionamiento de ambas implementaciones o a con un set particular de valores de T , M y N .

Parte 3. Primitivas de sincronizacin o

El sistema Nachos utiliza semforos, locks y variables de condicin para sincronizar threads y evitar a o los problemas que se presentaron en la parte anterior. A modo de ejemplo, la clase SynchList es una versin sincronizada de List que utiliza estas primitivas para garantizar un funcionamiento correcto, indeo pendientemente de la ocurrencia de cambios de contexto. Originalmente, la unica primitiva de sincronizacin o implementada en Nachos es el semforo. a En esta etapa se debe completar el sistema de hebras de Nachos, agregando soporte para locks y variables de condicin. Las interfaces pblicas para locks y variables de condicin estn denidas en threads/synch.h. o u o a Tambin se encuentran ah algunos comentarios importantes que denen la semntica de esas primitivas. e a Respete esa interfaz y usela tal como se dene ah La clase SynchList es un buen ejemplo de cmo se . o ocupan las primitivas de sincronizacin en Nachos. o Lo primero que debe hacer es denir los datos privados para las clases denidas en threads/synch.h e implementar las interfaces en thread/synch.cc. Para ello debe utilizar los semforos como unica primitiva de a sincronizacin. Note que la implementacin de semforos de Nachos deshabilita y habilita las interrupciones o o a cuando es necesario, con el objetivo de conseguir atomicidad. Para la implementacin que se pide no es o necesario (ni permitido) manipular las interrupciones directamente. La entrega de esta parte consiste de los archivos synch.h y synch.cc. Dato. Dentro de la evaluacin de esta parte se considerar el correcto funcionamiento de las primitivas de o a sincronizacin con una implementacin particular del problema de los productores y consumidores, por lo cual o o se recomienda probar su propia implementacin con las primitivas de sincronizacin recin implementadas. o o e

Parte 4. El problema de la Monta a Rusa. n

Como parte del ultimo proyecto de un parque de entretenciones, se desea construir una Montaa Rusa de n gigantescas proporciones. Para realizar una rigurosa evaluacin de su funcionamiento, se necesita programar o una simulacin del comportamiento de los supuestos clientes de dicha estructura. o La simulacin incluye C carros de pasajeros numerados de 1 a C, cada uno de capacidad P . Cada carro o llama a un procedimiento subir() con lo cual permite que un mximo de P pasajeros disponibles suban al a carro. Dado que slo hay una pista, y los carros no pueden pasarse unos a otros, stos deben llegar en el o e mismo orden en que parten. Al terminar una vuelta, el carro llama al procedimiento bajar() con lo cual todos los pasajeros que hab subido en el ultimo procedimiento subir() llamado por el carro, bajan de la an Montaa Rusa. La simulacin incluye a A pasajeros que llegan a la Montaa Rusa, con la intencin de dar V n o n o vueltas en ella. Para ello, los pasajeros llaman a la funcin vuelta() con la cual esperan para poder entrar o al prximo carro disponible. Una vez que los pasajeros bajan de un carro, inmediatamente vuelven a esperar o para subir al prximo, hasta completar las V vueltas. La simulacin termina cuando todos los pasajeros han o o completado las V vueltas, y se han retirado del juego. Implemente, en Nachos, una simulacin del problema de la Montaa Rusa para distintos valores de o n C, P , A y V , utilizando las primitivas de sincronizacin de Nachos que estime conveniente. Su solucin o o debe ser libre de bloqueos mutuos (deadlocks). No debe tener espera innecesaria, es decir, permitir que todos los pasajeros que estn esperando por un carro en un determinado instante, puedan subir inmediatamente e cuando ste lo permita (hasta un mximo de P pasajeros). Adems debe evitar inanicin (starvation); los e a a o pasajeros que bajan de un carro que ha terminado de dar una vuelta no pueden ingresar al siguiente carro antes que otro pasajero que ya estaba esperando. Tampoco se permite utilizar espera ocupada (busy waiting). Todos los parmetros deben ser recibido por l a nea de comandos.

La entrega de esta parte consiste en un archivo similar a threadtest.cc, de nombre montanarusa.cc con la implementacin de la simulacin dentro del entorno de Nachos. Incluya cualquier archivo adicional o o que necesite para la simulacin. Tenga en cuenta que para incluir ms archivos en la compilacin de Nachos, o a o debe modicar el archivo Makefile.common.

Recomendaciones
Siga cuidadosamente las instrucciones entregadas respecto al nombre de los archivos, y de los ags que se deben recibir por l nea de comandos con el n de facilitar la correccin. o Ilustre el comportamiento de los threads mediante mensajes claros, que permitan percibir lo que ocurre. Por ejemplo: Thread x inserta elemento y en el buffer, Pasajero i hace ingreso a la monta~a rusa por vez j, o Carro r inicia recorrido con s pasajeros. n Trabaje de manera incremental y ordenada, avanzando por cada etapa del proyecto de una a la vez. Se apreciarn los comentarios en el cdigo, o bien una apropiada explicacin en el informe. Al momento a o o de la evaluacin se privilegiar el orden, la claridad del cdigo, y las partes terminadas, por sobre las o a o incompletas. Procure entender el funcionamiento inicial del cdigo antes de introducir cambios. Para esto realice o pruebas del cdigo con pequeas variaciones de las funciones ThreadTest y SimpleThread. o n No intente escribir todo el cdigo de una sola vez para probarlo al nal. Una buena tcnica es escribir o e pequeos trozos, y compilarlos y probarlos poco a poco. n

Evaluacin o
30 %. Parte 2. Threads sin sincronizacin. o 15 %. Parte 3. Locks y variables de condicin. o 45 %. Parte 4. Montaa Rusa. n 10 %. Informe y claridad de implementacin. o

Entrega
La entrega debe hacerse dejando un directorio llamado exactamente nachosP1-entrega en el directorio base (HOME) del grupo. El retiro de las tareas se realizar de forma automtica a las 23:59 PM del d de la a a a entrega, por lo que deben tener cuidado con el nombre del directorio, ya que si ste no existe, se considerar la e a entrega como no-realizada. Consulte en el sitio web por las pol ticas de entrega. Dentro del directorio de entrega debe dejarse un archivo en formato ASCII llamado informeP1.txt, con un informe breve que incluya los siguientes puntos. Instrucciones de uso de los programas. Parte 2: Descripcin breve de los cuatro escenarios pedidos, y por qu se produce el comportamiento o e errneo. o Parte 3: Descripcin de la implementacin de locks y variables de condicin. o o o Parte 4: Descripcin de la simulacin y posibles limitaciones. o o La descripcin de las primitivas de sincronizacin, as como de la simulacin pueden incluirse como o o o comentarios en el cdigo, en lugar del informe, siempre y cuando esto facilite la claridad. o En un subdirectorio llamado threads se debe dejar todos los archivos necesarios (*.h, *.cc y Makefiles) para ejecutar sus programas. Esto incluye, como m nimo, thread-array.cc, thread-list.cc, synch.h, synch.cc, y montanarusa.cc.