Universidad Autnoma de Ciudad Jurez Instituto de Ingeniera y Tecnologa

Procesos con Hilos

Reporte

Nidia Vaquera Chvez

Matrcula 105328

Valeria Chvez Fernndez

Matrcula 98651

Ana Luz Ramrez Mateo

Matrcula 86505

Ingeniera en Sistemas Computacionales

Prof. No Ramn Rosales

Sistemas Operativos Distribuidos
Marzo 18, 2013

INTRODUCCIN
El propsito de esta prctica es el de realizar un programa en el que se pueda comparar el tiempo de ejecucin de un proceso respecto a otro utilizando hilos. Un hilo es una caracterstica que permite a un proceso realizar varias tareas a la vez, es decir, concurrentemente. Segn Tanenbaum en su libro de Sistemas Operativos (1987), en un proceso un hilo o thread es un contador de programa que indica cul es la siguiente instruccin a ejecutar. En pocas palabras, un hilo es una tarea que puede ser ejecutada al mismo tiempo con otra tarea. Los hilos permiten que haya mltiples ejecuciones en un mismo entorno determinado por un proceso. El escenario de mltiples instrucciones ejecutndose en paralelo dentro de un proceso es anlogo a tener mltiples procesos en un ordenador, con la diferencia de que los distintos hilos de ejecucin comparten una serie de recursos tales como el espacio de memoria, los archivos abiertos, situacin de autenticacin, etc. Esta tcnica permite simplificar el diseo de una aplicacin que debe llevar a cabo distintas funciones simultneamente. Un sistema multihilo, en un CPU con varios threads, por ejemplo, funciona con la CPU conmutndose rpidamente de unos threads a otros proporcionando la ilusin de que los threads se estn ejecutando en paralelo. Los hilos, al igual que los procesos pueden tener un estado, pueden estar: En ejecucin: estndo activos y teniendo la CPU Bloqueado: esperando que algn suceso lo desbloquee Preparado: planificado para que se ejecute y lo hace al llegar su turno Terminado

Cuando un proceso multihilo se ejecuta sobre un sistema con una nica CPU, los threads deber hacer turnos para ejecutarse. En la Figura 2-1 vimos cmo funciona la multiprogramacin de procesos. El sistema operativo crea la ilusin de que hay varios procesos secuenciales que se ejecutan en paralelo a base de ir conmutando la CPU entre esos procesos. Los sistemas multihilo funcionan de la misma manera. La CPU va conmutndose rpidamente de unos threads a otros proporcionando la ilusin de que los threads se estn ejecutando en paralelo, aunque sobre una CPU virtual ms lenta que la real. Con tres threads intensivos en computacin dentro de un proceso, los threads aparentan estar ejecutndose en paralelo, cada uno sobre una CPU con un tercio de la velocidad de la CPU real.
La organizacin de la Figura 2-6(a) puede utilizarse cuando los tres procesos estn esencialmente no relacionados, mientras que Figura 2-6(b) puede ser apropiada cuando los tres threads son realmente parte del mismo trabajo y cooperan activa y estrechamente uno con otro.

RAZONES PARA UTILIZAR HILOS

La razn principal para tener threads es que son numerosas las aplicaciones en las que hay varias actividades que estn en marcha simultnemente. De vez en cuando, alguna de estas actividades puede bloquearse. En esa situacin el modelo de programacin resulta ms sencillo si descomponemos tal aplicacin en varios threads secuenciales que se ejecutan en paralelo. Un segundo argumento para tener threads es que ya que no tienen ningn recurso ligado a ellos, son ms fciles de crear y destruir que los procesos. En numerosos sistemas, la creacin de un thread puede realizarse 100 veces ms rpido que la creacin de un proceso. Cuando el nmero de threads necesita cambiar dinmica y rpidamente, esa propiedad es efectivamente til. Una tercera razn para tener threads es tambin un argumento sobre el rendimiento. Los threads no proporcionan ninguna ganancia en el rendimiento cuando todos ellos utilizan intensamente la CPU, sino cuando hay una necesidad substancial tanto de clculo en la CPU como de E/S, de manera que teniendo threads se puede conseguir que esas dos actividades se solapen, acelerando la ejecucin de la aplicacin. Finalmente, los threads son tiles sobre sistemas con varias CPUs, donde es posible un paralelismo autntico.

EJEMPLO
Como primer ejemplo, consideremos un procesador de texto. La mayora de los procesadores de texto visualizan en la pantalla el documento que se est creando formateado exactamente como aparecera una vez impreso. En particular, todos los saltos de lnea y de pgina aparecen en su posicin correcta final, de forma que el usuario puede inspeccionarlos y modificar el documento si es necesario (por ejemplo eliminando las lneas viudas y hurfanas es decir las lneas de prrafos incompletos que aparecen en la parte de arriba y de abajo de una pgina, las cuales se consideran estticamente desagradables). Supongamos que el usuario est escribiendo un libro. Desde el punto de vista del autor es ms cmodo meter el libro entero en un nico fichero con el fin de hacer ms fcil la bsqueda por temas, realizar sustituciones globales, etc. Alternativamente, puede ponerse cada captulo en un fichero separado. Sin embargo teniendo cada seccin y subseccin como un fichero separado es un fastidio cuando hay que realizar modificaciones globales al libro entero ya que en ese caso puede ser necesario tener que editar cientos de ficheros. Por ejemplo si el estndar propuesto xxxx se aprueba justo antes de que el libro

vaya a la imprenta, entonces es necesario sustituir en el ltimo minuto todas las apariciones de el estndar propuesto xxxx por el estndar xxxx. Si el libro entero es un nico fichero, normalmente es suficiente con un nico comando para realizar todas las sustituciones. Por el contrario, si el libro se extiende sobre 300 ficheros, cada fichero debe editarse por separado. Consideremos ahora qu sucede cuando el usuario borra repentinamente una frase de la pgina 1 de un documento de 800 pginas. Despus de revisar la pgina modificada para asegurarse de que es correcta, el usuario puede querer realizar otra modificacin en la pgina 600 por lo que introduce un comando dicindole al procesador de texto que vaya a esa pgina (posiblemente pidindole que busque una frase que slo aparece en esa pgina). En ese caso, e procesador de texto se ve forzado a reformatear inmediatamente todo el libro hasta la pgina 600 ya que el procesador no puede saber cul es la primera lnea de la pgina 600 hasta que no haya procesado todas las pginas anteriores. Aqu puede producirse una espera considerable antes de que pueda visualizarse la pgina 600, encontrndonos entonces con un usuario descontento con el procesador de texto. En este caso los threads pueden ayudarnos. Supongamos que el procesador de texto est escrito como un programa con dos threads. Un thread interacta con el usuario y el otro realiza el reformateo como una actividad de fondo. Tan pronto como se borra la frase de la pgina 1, el thread interactivo indica al thread de reformateo que reformatee todo el libro. Mientras tanto, el thread interactivo contina atendiendo al teclado y al ratn y responde a comandos sencillos como realizar el scroll de la pgina 1 mientras el otro thread sigue trabajando frenticamente en un segundo plano. Con un poco de suerte, el reformateo se completa antes de que el usuario pida ver la pgina 600, de forma que en ese momento puede visualizarse instantneamente. Llegados a este punto, por qu no aadir un tercer thread? Muchos procesadores de texto ofrecen la posibilidad de salvar automticamente todo el fichero en el disco cada pocos minutos para proteger al usuario de la prdida de su trabajo diario a causa de un programa que se bloquea, una cada del sistema o un fallo del suministro elctrico. El tercer thread puede ocuparse de los backups (copias de seguridad, respaldos) en el disco sin interferir con los otros dos. La situacin con los tres threads se muestra en la Figura 2-9.

Si el programa correspondiente al procesador de texto tuviera tan slo un nico thread, se tendra que cada vez que comenzase un backup al disco, deberan ignorarse los comandos procedentes del teclado y del ratn hasta el momento en que el backup terminase. Est claro que el usuario podra percibir esa lentitud como un pobre rendimiento. De forma alternativa, podramos permitir que las seales del teclado y del ratn interrumpieran el backup al disco, haciendo posible obtener un buen rendimiento pero volviendo a caer en un complejo modelo de programacin dirigido por interrupciones. Con tres threads, el modelo de programacin es ms simple. El primer thread se limita a interactuar con el usuario. El segundo thread reformatea el documento cuando se le ordena. Finalmente el tercer thread escribe el contenido de la RAM al disco peridicamente. Est claro que aqu no funcionara bien tener tres procesos debido a que los tres threads necesitan operar sobre el documento. Teniendo tres threads en vez de tres procesos, se consigue que al compartir una memoria comn todos tengan acceso al documento que se est editando.

DESARROLLO DE LA PRCTICA
Nuestra implementacin de hilos para el desarrollo de esta prctica fue ejecutar el proceso de ordenar un lista en un arreglo de nmeros mediante distintos mtodos de ordenamiento. Por defecto sabemos que los diferentes mtodos de ordenamiento existentes tienen diferente eficiencia respecto a tiempo de ordenamiento. El mtodo de la burbuja, Shell, Quick Sort, Insercin, son algunos ejemplos de ellos. Entonces, la implementacin consiste en un programa sencillo en el que el arreglo de nmeros debe ordenarse mediante los mtodos de ordenamiento pero utilizando hilos. En el programa se aprecia cmo al correr dos hilos, uno para cada mtodo el arreglo se va ordenando, cada nmero con un nmero de hilo, ya sea el primero y segundo. As se puede ver para cada paso de ejecucin cmo se alternan los hilos y cul est actuando en tiempo real. Tambin se puede comparar, no por cantidad de tiempo especficamente, pero viendo cul termina primero. Tambin cabe mencionar que a los hilos se les asign una funcin de retardo sleep para jugar con los turnos y con la forma en que se ejecuten, ya sea dando ventaja a uno desventaja a otro para terminar primero segn se desee, dndole al proceso de ordenamiento las variables de la eficiencia del mtodo utilizado y del retardo.

LENGUAJE UTILIZADO
ECLIPSE Para la implementacin de la prctica nosotros decidimos utilizar Java debido a que este lenguaje de programacin tiene caractersticas de diseo expresamente creadas para permitir a los usuarios programadores lidiar con hilos de ejecucin. Especficamente en Java los hilos estn en el paquete. java.lang.thread. En Java, el proceso que siempre se ejecuta es el llamado main que es a partir del cual se inicia prcticamente todo el comportamiento de nuestra aplicacin, y un hilo o Thread puede ser 2 cosas: Un proceso en ejecucin Una instancia de la clase java.lang.Thread

En nuestro caso una instancia de la clase java.lang.Thread, no es ms que cualquier otro objeto, con variables y mtodos predefinidos. Un proceso en ejecucin es un proceso individual que realiza una tarea o trabajo, tiene su propia pila de informacin independiente a la de la aplicacin principal. Algunos mtodos relacionados que siempre tenemos que tener presentes con respecto a los hilos son:

start() yield() sleep() run()

En nuestro programa se utilizaron start() y sleep() por ejemplo para iniciar los hilos y darles el retardo antes mencionado. Al hablar de multi-hilo pudiera parecer que necesitamos ms de un procesador para realizar dichas tareas pero no es as, el procesador mismo junto con la mquina virtual de Java gestionan el flujo de trabajo y dan la impresin de que se puede ejecutar ms de algn proceso al mismo tiempo, aunque en trminos estrictos eso no es posible. En Java, 2 o ms procesos pueden ejecutarse al mismo tiempo dentro de una misma aplicacin y para ello son necesarios los Threads o hilos.

ANEXOS

*Programa*

Main.java

10

Hilos.java (ordenamiento por burbuja)

11

Insertion.java (ordenamiento por insercin)

12

Quick.java (ordenamiento por quicksort)

13

RESULTADOS Y CONCLUSIONES

*Pruebas al programa*
Prueba 1 Mtodos con especificacin de retraso diferente.

1.- Indicaremos que deseamos el ordenamiento del siguiente arreglo de nmeros:

2. Como especificacin daremos un tiempo determinado entre cada proceso, los cuales sern: Hilo1.sleep:burbuja ins2.sleep:Insercion Quick2.sleep:quicksort

3. Correremos el programa con los 3 mtodos de ordenamiento ya mencionados: Los resultados fueron los siguientes:

Ordenamiento por burbuja (Inicio/Termino) Ordenamiento por insercin (Inicio/Termino) Ordenamiento por quicksort (Inicio/Termino) Los resultados muestran que el ordenamiento por burbuja es el primero en terminar ya que tiene como especificacin sleep 2 de retraso (menor), el ordenamiento por insercin es el segundo proceso en terminar ya que tiene como retraso 100, y por ultimo tenemos el ordenamiento quicksort, el cual tiene el mayor retraso de los 3. En este caso el ordenamiento ms rpido fue burbuja.

14

Prueba 2 Mtodos sin especificacin de retraso.

1.- Indicaremos el mismo ordenamiento de la prueba del siguiente arreglo de nmeros:

2. Como especificacin NO daremos un tiempo determinado entre cada proceso, los cuales sern: Hilo1.sleep: burbuja ins2.sleep: Insercin Quick2.sleep:quicksort (los retrasos sern comentados)

3. Correremos el programa con los 3 mtodos de ordenamiento ya mencionados: Los resultados fueron los siguientes:

Ordenamiento por quicksort (Inicio/Termino) Ordenamiento por burbuja (Inicio/Termino) Ordenamiento por insercin (Inicio/Termino) Los resultados muestran ahora un cambio notorio, el ordenamiento quicksort termino como primero ahora que ya no tiene ninguna especificacin de retraso, seguido por burbuja y despus por insercin. 15

Prueba3 Mtodos con especificacin de retraso diferente al prueba 1. 1.- Indicaremos que deseamos el ordenamiento del siguiente arreglo de nmeros:

2. Como especificacin daremos un tiempo determinado entre cada proceso, los cuales sern: Hilo1.sleep: burbuja ins2.sleep: Insercion Quick2.sleep: quicksort

3. Correremos el programa con los 3 mtodos de ordenamiento ya mencionados: Los resultados fueron los siguientes:

Ordenamiento por quicksort (Inicio/Termino) Ordenamiento por burbuja (Inicio/Termino) Ordenamiento por insercin (Inicio/Termino) Los resultados muestran la misma secuencia que en el caso interior debido a que quicksort es el proceso que tiene menos retraso de los 3, insercin es el mayor retraso de todos (adems de ya ser el ms lento) es por esto que se ejecutara de ultimo.

16

Conclusin de equipo.
En nuestro programa el proceso que se ejecut con mayor rapidez y el que mostro ms estabilidad durante las pruebas fue el ordenamiento por quicksort, su explicacin est en que es una tcnica basada en otra conocida con el nombre divide y vencers, que permite ordenar una cantidad de elementos en un tiempo proporcional a n2. El segundo en realizar el ordenamiento fue el proceso burbuja, aunque sea un mtodo muy simple de realizar, no tiene la velocidad de quicksort, que divide los datos para compararlos entre s, si no que compara numero por numero hasta ordenarlos. Estos dos mtodos se realizan por medio de un proceso de intercambio, es por eso que dejaron muy atrs a el proceso de insercin, que es un proceso, a el proceso de insercin que se realiza por medio de intercambio es llamado shellsort. Aunque a los metodos se les diera un retraso los dos primeros seguan siendo los mejores a comparacin con insercion, a menos de que tuvieran un retraso muy grande.

BIBLIOGRAFA
Tanenbaum A. Sistemas Operativos Distribuidos, Prentice Hall Iberoamericana, Primera Edicin, Mxico, 1996. http://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.html

17