Programación Por Threads

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 23

UNIVERSIDAD NACIONAL DE UCAYALI

FACULTAD DE INGENIERIA DE SISTEMAS Y DE INGENIERIA CIVIL


ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

TEMA:

PROGRAMACIÓN POR THREADS

ASIGNATURA : SISTEMAS OPERATIVOS

DOCENTE : DR. CESAR AYRA APAC

ESTUDIANTE : ROJAS AGUILAR AMERICO

CICLO : VII

FECHA : 04/05/2017

Pucallpa – Perú

2017
i
PROGRAMACIÓN POR THREADS

DEDICATORIA

A Dios
Por iluminarme durante este
Informe y por permitirnos finalizarlo
Con éxito.

-A mis padres
Por sus apoyos incondicionales y el
esfuerzo diario que realizan por
brindarme una buena educación.

II
PROGRAMACIÓN POR THREADS

AGRADECIMIENTO

Agradecer a Dios. A mis padres y


Al Dr. Cesar Ayra Apac quien me
Ayudo en todo para hacer realidad
Este informe.

III
PROGRAMACIÓN POR THREADS

ÍNDICE
CONTRAPORTADA I
DEDICATORIA ii
AGRADECIMIENTO iii
INDICE iv
INTRODUCCIÓN v

IV
INTRODUCCIÓN

El presente informe acerca de “PROGRAMACIÓN POR THREADS” En sistemas


operativos, un hilo de ejecución, hebra o subproceso es una secuencia de tareas
encadenadas muy pequeña que puede ser ejecutada por un sistema operativo.

La destrucción de los hilos antiguos por los nuevos es una característica que no
permite a una aplicación realizar varias tareas a la vez (concurrentemente). Los
distintos hilos de ejecución comparten una serie de recursos tales como el espacio
de memoria, los archivos abiertos, la situación de autenticación, etc. Esta técnica
permite simplificar el diseño de una aplicación que debe llevar a cabo distintas
funciones simultáneamente.

Un hilo es simplemente una tarea que puede ser ejecutada al mismo tiempo que
otra tarea.

Los hilos de ejecución que comparten los mismos recursos, sumados a estos
recursos, son en conjunto conocidos como un proceso. El hecho de que los hilos
de ejecución de un mismo proceso compartan los recursos hace que cualquiera de
estos hilos pueda modificar estos recursos. Cuando un hilo modifica un dato en la
memoria, los otros hilos acceden a ese dato modificado inmediatamente.

El proceso sigue en ejecución mientras al menos uno de sus hilos de ejecución siga
activo. Cuando el proceso finaliza, todos sus hilos de ejecución también han
terminado. Asimismo en el momento en el que todos los hilos de ejecución finalizan,
el proceso no existe más y todos sus recursos son liberados.

El tema se ha divido en tres capítulos:

Capítulo I : Aspectos Generales

Capítulo II : Marco Teórico

Capítulo III : Programación en Threads

5
PROGRAMACIÓN POR THREADS

CAPÍTULO I
ASPECTOS GENERALES

1.1. DEFINICION

Un Thread es un mecanismo que permite a una aplicación realizar varias tareas a


la vez de manera concurrente.

Se les parece al concepto de sistema operativo multitarea?


Sí, es parecido, es la misma filosofía que utiliza el OS para ejecutar varios procesos
a la vez, pero enfocada ejecutar sub procesos de un mismo proceso, lo cual es un
poco diferente ya que por definición los procesos no comparten el espacio de
memoria entre si, mientras que los Threads (o hilos como los quieras llamar) si.

Los Threads son una ampliación del concepto de multitarea, si bien multitarea se
refiere a la capacidad de un sistema para ejecutar varios procesos a la vez, en un
comienzo esto hacia referencia a que más de una aplicación se estuviera
ejecutando de manera concurrente, sin embargo pronto se hizo notoria la necesidad
de que una misma aplicación hiciera varias cosas a la vez. Allí nacieron los Threads.

En un sistema multitarea podemos tener los procesos A, B y C ejecutándose


simultáneamente, pero ¿qué pasaba si el proceso A debía mostrar una interfaz
gráfica y de paso estar escribiendo un archivo a la vez? no era posible.

El proceso debía terminar de escribir en disco antes de volver a trabajar en su


interfaz gráfica lo cual no era precisamente algo deseable. Así que surgió la idea
de permitir que un proceso pueda tener una o mas tareas ejecutándose a la vez o
al menos que así lo percibiera el usuario, de tal forma que cada vez que a un
proceso le correspondiera un Quantum de ejecución el sistema alterne entre
ejecutar una de sus tareas u otra.

Esto conlleva a la necesidad de reestructurar el concepto de proceso, ya que un


proceso no es la unidad mínima de ejecución puesto que ahora el proceso es un
conjunto de tareas (en adelante hilos o threads).

Un proceso que en apariencia no utiliza threads realmente se esta ejecutando en


un único thread.

6
PROGRAMACIÓN POR THREADS

1.2. FUNCIONALIDAD DE LOS HILOS

Al igual que los procesos, los hilos poseen un estado de ejecución y pueden
sincronizarse entre ellos para evitar problemas de compartición de recursos.
Generalmente, cada hilo tiene una tarea especifica y determinada, como forma de
aumentar la eficiencia del uso del procesador.

Estados de un hilo

Los principales estados de los hilos son: Ejecución, Listo y Bloqueado. No tiene
sentido asociar estados de suspensión de hilos ya que es un concepto de proceso.
En todo caso, si un proceso está expulsado de la memoria principal (RAM), todos
sus hilos deberán estarlo ya que todos comparten el espacio de direcciones del
proceso.

Cambio de estados

Creación: Cuando se crea un proceso se crea un hilo para ese proceso. Luego, este
hilo puede crear otros hilos dentro del mismo proceso, proporcionando un puntero
de instrucción y los argumentos del nuevo hilo. El hilo tendrá su propio contexto y
su propio espacio de la columna, y pasará al final de los Listos.
Bloqueo: Cuando un hilo necesita esperar por un suceso, se bloquea (salvando sus
registros de usuario, contador de programa y punteros de pila). Ahora el procesador
podrá pasar a ejecutar otro hilo que esté al principio de los Listos mientras el anterior
permanece bloqueado.
Desbloqueo: Cuando el suceso por el que el hilo se bloqueó se produce, el mismo
pasa a la final de los Listos.
Terminación: Cuando un hilo finaliza se liberan tanto su contexto como sus
columnas.

7
PROGRAMACIÓN POR THREADS

1.3. SINCRONIZACIÓN DE HILOS

Todos los hilos comparten el mismo espacio de direcciones y otros recursos como
pueden ser archivos abiertos. Cualquier modificación de un recurso desde un hilo
afecta al entorno del resto de los hilos del mismo proceso. Por lo tanto, es necesario
sincronizar la actividad de los distintos hilos para que no interfieran unos con otros
o corrompan estructuras de datos.

Una ventaja de la programación multihilo es que los programas operan con mayor
velocidad en sistemas de computadores con múltiples CPUs (sistemas
multiprocesador o a través de grupo de máquinas) ya que los hilos del programa se
prestan verdaderamente para la ejecución concurrente. En tal caso el programador
necesita ser cuidadoso para evitar condiciones de carrera (problema que sucede
cuando diferentes hilos o procesos alteran datos que otros también están usando),
y otros comportamientos no intuitivos.

Los hilos generalmente requieren reunirse para procesar los datos en el orden
correcto. Es posible que los hilos requieran de operaciones atómicas para impedir
que los datos comunes sean cambiados o leídos mientras estén siendo
modificados, para lo que usualmente se utilizan los semáforos. El descuido de esto
puede generar interbloqueo.

1.4. FORMAS DE MULTIHILOS

Los sistemas operativos generalmente implementan hilos de dos maneras:

Multihilo apropiativo: permite al sistema operativo determinar cuándo debe


haber un cambio de contexto. La desventaja de esto es que el sistema puede
hacer un cambio de contexto en un momento inadecuado, causando un fenómeno
conocido como inversión de prioridades y otros problemas.
Multihilo cooperativo: depende del mismo hilo abandonar el control cuando llega
a un punto de detención, lo cual puede traer problemas cuando el hilo espera la
disponibilidad de un recurso.
El soporte de hardware para multihilo se encuentra disponible desde hace mucho
tiempo, en los 386 por ejemplo http://en.wikipedia.org/wiki/Compaq_SystemPro
Hace relativamente poco tiempo, Esta característica es utilizada por el gran
público, Soportada nativamente por los Intel en el Pentium Pro y los pentium II y III

8
PROGRAMACIÓN POR THREADS

en la versión doméstica, eliminada posteriormente en los celeron, al descubrirse


que podía ser desbloqueado, y posteriormente reintroducido en el Pentium 4, bajo
el nombre de HyperThreading.

1.5. USOS MÁS COMUNES

Los usos más comunes son en tecnologías SMPP y SMS para la


telecomunicaciones aquí hay muchísimos procesos corriendo a la vez y todos
requiriendo de un servicio.

Trabajo interactivo y en segundo plano


Por ejemplo, en un programa de hoja de cálculo un hilo puede estar visualizando
los menús y leer la entrada del usuario mientras que otro hilo ejecuta las órdenes y
actualiza la hoja de cálculo. Esta medida suele aumentar la velocidad que se
percibe en la aplicación, permitiendo que el programa pida la orden siguiente antes
de terminar la anterior.

Procesamiento asíncrono
Los elementos asíncronos de un programa se pueden implementar como hilos. Un
ejemplo es como los software de procesamiento de texto guardan archivos
temporales cuando se está trabajando en dicho programa. Se crea un hilo que tiene
como función guardar una copia de respaldo mientras se continúa con la operación
de escritura por el usuario sin interferir en la misma. Son como 2 programas
independientes.

Aceleración de la ejecución
Se pueden ejecutar, por ejemplo, un lote mientras otro hilo lee el lote siguiente de
un dispositivo.

Estructuración modular de los programas


Puede ser un mecanismo eficiente para un programa que ejecuta una gran variedad
de actividades, teniendo las mismas bien separadas mediante hilos que realizan
cada una de ellas.

9
PROGRAMACIÓN POR THREADS

1.6. IMPLEMENTACIONES

Hay dos grandes categorías en la implementación de hilos:

 Hilos a nivel de usuario.


 Hilos a nivel de kernel.

También conocidos como ULT (user level thread) y KLT (kernel level thread)

Hilos a nivel de usuario (ULT)

En una aplicación ULT pura, todo el trabajo de gestión de hilos lo realiza la


aplicación y el núcleo o kernel no es consciente de la existencia de hilos. Es posible
programar una aplicación como multihilo mediante una biblioteca de hilos. La misma
contiene el código para crear y destruir hilos, intercambiar mensajes y datos entre
hilos, para planificar la ejecución de hilos y para salvar y restaurar el contexto de
los hilos.

Todas las operaciones descritas se llevan a cabo en el espacio de usuario de un


mismo proceso. El kernel continua planificando el proceso como una unidad y
asignándole un único estado (Listo, bloqueado, etc.).

Ventajas de los ULT

 El intercambio de los hilos no necesita los privilegios del modo kernel, porque
todas las estructuras de datos están en el espacio de direcciones de usuario de
un mismo proceso. Por lo tanto, el proceso no debe cambiar a modo kernel para
gestionar hilos. Se evita la sobrecarga de cambio de modo y con esto el
sobrecoste u overhead.
 Se puede realizar una planificación específica. Dependiendo de que aplicación
sea, se puede decidir por una u otra planificación según sus ventajas.
 Los ULT pueden ejecutar en cualquier sistema operativo. La biblioteca de hilos
es un conjunto compartido.

10
PROGRAMACIÓN POR THREADS

Desventajas de los ULT

 En la mayoría de los sistemas operativos las llamadas al sistema (System calls)


son bloqueantes. Cuando un hilo realiza una llamada al sistema, se bloquea el
mismo y también el resto de los hilos del proceso.
 En una estrategia ULT pura, una aplicación multihilo no puede aprovechar las
ventajas de los multiprocesadores. El núcleo asigna un solo proceso a un solo
procesador, ya que como el núcleo no interviene, ve al conjunto de hilos como
un solo proceso.

Una solución al bloqueo mediante a llamadas al sistema es usando la técnica


de jacketing, que es convertir una llamada bloqueante en no bloqueante; esto se
consigue comprobando previamente si la llamada al sistema bloqueará el proceso
o no. Si es así, se bloquea el hilo y se pasa el control a otro hilo. Más adelante se
reactiva el hilo bloqueado y se vuelve a realizar la comprobación, hasta que se
pueda realizar la llamada al sistema sin que el proceso completo sea bloqueado.

Hilos a nivel de núcleo (KLT)

En una aplicación KLT pura, todo el trabajo de gestión de hilos lo realiza el kernel.
En el área de la aplicación no hay código de gestión de hilos, únicamente
un API (interfaz de programas de aplicación) para la gestión de hilos en el
núcleo. Windows 2000, Linux y OS/2 utilizan este método. Linux utiliza un método
muy particular en el que no hace diferencia entre procesos e hilos. Para Linux, si
varios procesos creados con la llamada al sistema "clone" comparten el mismo
espacio de direcciones virtuales, el sistema operativo los trata como hilos, y
lógicamente son manejados por el kernel.

Ventajas de los KLT

 El kernel puede planificar simultáneamente múltiples hilos del mismo proceso


en múltiples procesadores.
 Si se bloquea un hilo, puede planificar otro del mismo proceso.
 Las propias funciones del kernel pueden ser multihilo.

11
PROGRAMACIÓN POR THREADS

Desventajas de los KLT

 El paso de control de un hilo a otro precisa de un cambio de modo.

Combinaciones ULT y KLT

Algunas distribuciones de linux y derivados de UNIX ofrecen la combinación de ULT


y KLT, como Solaris, Ubuntu y Fedora.

La creación de hilos, así como la mayor parte de la planificación y sincronización de


los hilos de una aplicación se realiza por completo en el espacio de usuario. Los
múltiples ULT de una sola aplicación se asocian con varios KLT. El programador
puede ajustar el número de KLT para cada aplicación y máquina para obtener el
mejor resultado global.

En un método combinado, los múltiples hilos de una aplicación se pueden ejecutar


en paralelo en múltiples procesadores y las llamadas al sistema bloqueadoras no
necesitan bloquear todo el proceso.

CAPÍTULO II
MARCO TEORICO

2.1. DESCRIPCIONES.
Dado lo que he explicado anteriormente podemos contemplar los siguientes
aspectos:

Los thread de usuario (fibers) son mucho más eficientes en escenarios con
varios thread que los thread del kernel. Principalmente por dos razones:

1. Los thread de usuario no requieren ser conmutados en modo kernel


sino en modo usuario lo cual permite hacer la conmutación entre
threads de manera más rápida al no tener que alternar de contexto.

2. No son calendarizados de manera preferente, sino que de manera


‘manual’ deben ser suspendidos o reactivados, lo que da la opción de
hacer una calendarización mucho más adecuada de acuerdo al juego
de threads que se estén ejecutando.

12
PROGRAMACIÓN POR THREADS

Los thread de usuario tienen la desventaja de que no tienen mayor soporte


del sistema operativo lo que conlleva a que hay que hacer mucho trabajo de
manera manual, por ejemplo efectuar la calendarización.

Los thread de usuario bloquean a todos los thread del proceso cuando estos
están bloqueados a espera de una llamada al kernel o a un dispositivo de
IO, lo cual hace que se pierda la funcionalidad de procesamiento paralelo.

Algunos sistemas operativos como es el caso de Windows, proveen


funcionalidades para convertir fiber a kernel thread y viceversa, lo cual facilita
dar solución a estos escenarios de bloqueo.

En términos generales es mucho más recomendable trabajar con Kernel


Threads que con Fibers, dada su mayor complejidad los fibers pueden traer
más problemas de lo que solucionan. Sin embargo hay escenarios donde la
implementación de fibers es muy recomendable y de hecho casi un deber
como es en los siguientes casos:

1. migrar una aplicación de Linux/Unix a Windows

2. crear un runtime de ejecución de programas como es el caso del CLR


o del java virtual machine.

3. crear una aplicación profundamente compleja e intensiva a nivel de


manejo de threads

Usar thread no implica necesariamente ejecución en paralelo

Qué sucede si estamos utilizando varios threads en una aplicación que se ejecuta
en una maquina con una sola CPU?

Si bien la impresión del usuario es que se están ejecutando varias cosas al tiempo
ya esta claro que esto no es así pues en la CPU solo se puede ejecutar una cosa a
la vez, lo que esta pasando realmente es que los thread están alternando tiempo
de ejecución de una manera tan rápida que el usuario percibe que se están
ejecutando al tiempo.

13
PROGRAMACIÓN POR THREADS

Pero por otro lado...

Qué sucede si la maquina tiene más de una CPU?

En este caso las cosas pueden cambiar, si nuestra aplicación tiene dos hilos y
nuestra maquina tiene dos CPU (o core) en efecto cada thread se podría ejecutar
en una CPU diferente, en este caso si se puede habar de ejecución en paralelo,
aunque no necesariamente pues puede darse el caso en que, debido a la necesidad
del sistema de calendarizar threads de otros procesos, ambos thread se ejecuten
en la misma CPU en un momento dado, en ese momento no habría paralelismo.

Pero hay otro escenario

Que pasa si mi maquina tiene 2 CPU pero mi aplicación esta utilizando más de 2
thread?

Lo que sucederá es que solo dos de esos thread se estarán ejecutando en paralelo
en un momento dado (aunque ya vimos que esto no es necesariamente lo que
sucede), y el sistema operativo alternara la ejecución de dichos thread de tal forma
que todos tengan Quantums asignados, pero solo podrá haber máximo 2 en
paralelo.

¿Es cierto que usar threads hará que mi aplicación se ejecute más rápido?

De acuerdo a lo que vimos en la sección anterior podemos concluir rotundamente


que: DEPENDE.

Como ya vimos si tu maquina tiene solo 1 CPU realmente hará tu aplicación mas
lenta, pero con la ventaja de poder efectuar varias tareas a la vez (en apariencia),
pero si tienes tantas o más CPU como threads en ejecución el rendimiento si que
mejorara, es decir si tienes 2 thread y 2 CPU seguramente que si estarás haciendo
dos cosas a la vez y no una cosa cada vez.

El efecto contrario se evidencia toda vez que trates de ejecutar más threads que las
CPU que tienes, es decir si vas a ejecutar 20 threads y solo tienes 2 CPU en vez
de ganar rendimiento realmente lo que harás será castigarlo puesto que esos thread
estarán compitiendo por el tiempo de CPU, lo cual se traduce en múltiples y
frecuentes cambios de contexto que harán perder el preciado tiempo de CPU en la
lógica necesaria par cambiar de un thread a otro.

14
PROGRAMACIÓN POR THREADS

En estos escenarios es conveniente administrar la ejecución de los thread para que


solo se ejecuten tantos thread como CPUS existan, y solo entren en ejecución
threads nuevos cuando haya CPUS disponibles. Esto es muy engorroso de hacer
pero ya hay librerias que ayudan a esto como es el caso de TPL y sus derivados a
nivel de lenguaje async/await.

Otra cosa importante de notar es que la creación y la administración de threads es


costosa desde el punto de vista del uso de CPU así que si una aplicación que se
ejecuta en una maquina con más de una CPU, requiere ejecutar una tarea cortada
en partes paralelas probablemente sea mucho mas rápido ejecutarla normalmente
que abrirla en threads, mientras que en una tareas suficientemente grande el tiempo
invertido en crear y administrar los threads puede ser proporcionalmente
insignificante.

CAPÍTULO III
PROGRAMACION POR THREADS

3.1. FUNCIONALIDAD DE LA PROGRAMACION POR THREADS.

En esta entrada vamos a ver las diferentes maneras de como trabajar con Threads
en Java (o hilos en español). Sino tienes muy claro el concepto de la multitarea te
recomendamos que te leas primero la entrada de Multitaréa e Hilos, fácil y muchas
ventajas aunque en esta entrada también veremos (en menor detalle) los conceptos
y las ventajas de la multitarea.

En esencia la multitarea nos permite ejecutar varios procesos a la vez; es decir, de


forma concurrente y por tanto eso nos permite hacer programas que se ejecuten en
menor tiempo y sean más eficientes. Evidentemente no podemos ejecutar infinitos
procesos de forma concurrente ya que el hardware tiene sus limitaciones, pero raro
es a día de hoy los ordenadores que no tengan más de un núcleo por tanto en un
procesador con dos núcleos se podrían ejecutar dos procesos a la vez y así nuestro
programa utilizaría al máximo los recursos hardware. Para que veáis la diferencia
en un par de imágenes, supongamos que tenemos un programa secuencial en el

15
PROGRAMACIÓN POR THREADS

que se han de ejecutar 4 procesos; uno detrás de otro, y estos tardan unos
segundos:

Si en vez de hacerlo de forma secuencial, lo hiciésemos con 4 hilos, el programa


tardaría en ejecutarse solo 20 segundos, es decir el tiempo que tardaría en
ejecutarse el proceso más largo. Esto evidentemente sería lo ideal, pero la realidad
es que no todo se puede paralelizar y hay que saber el número de procesos en
paralelo que podemos lanzar de forma eficiente. En principio en esta entrada no
vamos a hablar sobre ello ya que el objetivo de la misma es ver como se utilizan los
hilos en java con un ejemplo relativamente sencillo y didáctico.

En Java para utilizar la multitarea debemos de usar la clase Thread (es decir que la clase
que implementemos debe heredar de la clase Thread) y la clase Thread implementa la
Interface Runnable. En el siguiente diagrama de clase mostramos la Interface Runnable y
la clase Thread con sus principales métodos:

16
PROGRAMACIÓN POR THREADS

En esta entrada no vamos a ver como utilizar todos los métodos de la clase Thread, pero
os los mostramos para que sepáis que existen y a parte por su nombre podéis intuir su
funcionalidad.

En esta entrada vamos a poner un ejemplo para que veáis las ventajas de la multitarea,
viendo como se ejecutaría un programa sin utilizar la multitarea y otro utilizándola.

En este ejemplo vamos a simular el proceso de cobro de un supermercado; es decir, unos


clientes van con un carro lleno de productos y una cajera les cobra los productos,
pasándolos uno a uno por el escaner de la caja registradora. En este caso la cajera debe
de procesar la compra cliente a cliente, es decir que primero le cobra al cliente 1, luego al
cliente 2 y así sucesivamente. Para ello vamos a definir una clase "Cajera" y una clase
"Cliente" el cual tendrá un "array de enteros" que representaran los productos que ha
comprado y el tiempo que la cajera tardará en pasar el producto por el escaner; es decir,
que si tenemos un array con [1,3,5] significará que el cliente ha comprado 3 productos y
que la cajera tardara en procesar el producto 1 '1 segundo', el producto 2 '3 segundos' y el
producto 3 en '5 segundos', con lo cual tardara en cobrar al cliente toda su compra '9
segundos'.

17
PROGRAMACIÓN POR THREADS

Explicado este ejemplo vamos a ver como hemos definido estas clases:

Clase "Cajera.java":

Si ejecutásemos este programa propuesto con dos Clientes y con un solo proceso
(que es lo que se suele hacer normalmente), se procesaría primero la compra del
Cliente 1 y después la del Cliente 2, con lo cual se tardará el tiempo del Cliente 1 +
Cliente 2. A continuación vamos a ver como programamos el método Main para
lanzar el programa. CUIDADO: Aunque hayamos puesto dos objetos de la clase
Cajera (cajera1 y cajera2) no significa que tengamos dos cajeras independientes,
lo que estamos diciendo es que dentro del mismo hilo se ejecute primero los
métodos de la cajera1 y después los métodos de la cajera2, por tanto a nivel de
procesamiento es como si tuviésemos una sola cajera:

18
PROGRAMACIÓN POR THREADS

19
PROGRAMACIÓN POR THREADS

20
PROGRAMACIÓN POR THREADS

21
PROGRAMACIÓN POR THREADS

CONCLUSIONES

El concepto de multitarea o multiprocesamiento es bastante sencillo de entender ya


que solo consiste en hacer varias cosas a la vez sin que se vea alterado el resultado
final. Como ya se ha dicho en la entrada no todo se puede paralelizar y en muchas
ocasiones suele ser complicado encontrar la manera de paralelizar procesos dentro
de una aplicación sin que esta afecte al resultado de la misma, por tanto aunque el
concepto sea fácil de entender el aplicarlo a un caso práctico puede ser complicado
para que el resultado de la aplicación no se vea afectado.

Por otro lado para los que empecéis a ver estos temas de la concurrencia,
multitarea y demás, no so preocupéis al principio si os cuesta programar problemas
de este tipo ya que a parte de la multitarea se mezclan cosas como la herencia y
las Interfaces que al principio son cosas que cuestan de asimilar, así que ir poco a
poco pero tener muy claro que la multitarea es muy util y se ha de aplicar para hacer
las aplicaciones más eficientes y que den mejor rendimiento.

22
PROGRAMACIÓN POR THREADS

BIBLIOGRAFIA

http://codigoprogramacion.com/cursos/java/133-uso-de-hilos-o-threads-en-
java.html#.WQyqRuWGO00

https://jarroba.com/multitarea-e-hilos-en-java-con-ejemplos-thread-runnable/

23

También podría gustarte