7/30/2019 Reporte Hilos

1/17

7/30/2019 Reporte Hilos

2/17

Prof. No Ramn Rosales

Sistemas Operativos Distribuidos

Marzo 18, 2013

2

7/30/2019 Reporte Hilos

3/17

INTRODUCCINEl 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

3

7/30/2019 Reporte Hilos

4/17

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 norelacionados, 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.

4

7/30/2019 Reporte Hilos

5/17

RAZONES PARA UTILIZAR HILOSLa 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.

EJEMPLOComo 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

5

7/30/2019 Reporte Hilos

6/17

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 scrollde 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 semuestra en la Figura 2-9.

6

7/30/2019 Reporte Hilos

7/17

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.

7

7/30/2019 Reporte Hilos

8/17

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 sleeppara 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 UTILIZADOECLIPSE

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, elproceso 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 clasejava.lang.Thread

8

http://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.html

7/30/2019 Reporte Hilos

9/17

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.

9

7/30/2019 Reporte Hilos

10/17

ANEXOS

*Programa*

Main.java

10

7/30/2019 Reporte Hilos

11/17

Hilos.java (ordenamiento por burbuja)

11

7/30/2019 Reporte Hilos

12/17

Insertion.java (ordenamiento por insercin)

12

7/30/2019 Reporte Hilos

13/17

Quick.java (ordenamiento por quicksort)

13

7/30/2019 Reporte Hilos

14/17

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

7/30/2019 Reporte Hilos

15/17

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 comoprimero ahora que ya no tiene ninguna especificacin de retraso, seguido por burbuja y

despus por insercin.

15

7/30/2019 Reporte Hilos

16/17

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

7/30/2019 Reporte Hilos

17/17

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 esllamado 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, PrimeraEdicin, Mxico, 1996.

http://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.html

17

http://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.htmlhttp://monillo007.blogspot.com/2008/01/hilos-en-java-threads-parte-1.html