Licenciatura en Ciencias de la Computación, Facultad de Ciencias, UNAM. Computación concurrente. Profesor: Carlos Zerón Martínez. Ayudante: Manuel Ignacio Castillo López.

Notas de clase Threads Introducción Ya hemos visto que al desarrollar aplicaciones gráficas en Java, el comportamiento de la misma no está regido estrictamente por el método main; sino que usualmente la aplicación espera a que el usuario haga alguna petición. Pero ¿cómo funciona esta espera? ¿este comportamiento es propio de las interfaces gráficas? Lo anterior es posible gracias a los hilos de ejecución. Cualquier tipo de aplicación puede tener más de un hilo y todos influyen en el comportamiento de la misma. Las aplicaciones gráficas en particular, tienen más de un hilo para: atender al usuario (los eventos, en niveles más bajos; son interrupciones y un hilo o más responden a estas), para dibujar la pantalla (de lo contrario la aplicación pasaría la mayor parte de su tiempo irresponsiva, mientras refresca la memoria de vídeo); entre otras. En cualquier plataforma, todo proceso tiene por lo menos un hilo. En el caso particular de la programación en Java; al invocar un programa, se le asigna un hilo principal donde se ejecuta su método main: cada programa corre en su propio hilo. A partir de main, la aplicación puede crear más hilos: tantos como los necesite. Este comportamiento es muy similar en muchas otras plataformas de desarrollo de software. Es importante mencionar que estos nuevos hilos son concurrentes, ya que se ejecutan al mismo tiempo en la misma máquina. Además, el programa no terminará de ejecutarse sino hasta que todos sus hilos terminen de hacer también: no importa que el hilo del método main termine antes que todos los demás; mientras otros hilos continúen ejecutándose, la aplicación también lo hará. Ejercicio. Revise el ejemplo “Interfaz no responsiva”. Observe con detalle los métodos que gestionan los eventos de los botones y ejecute el programa. ¿por qué la aplicación se congela hasta terminar de contar? Hilos en Java Si queremos crear un programa en Java que realice más de una tarea al mismo tiempo; podríamos tomar la estrategia clásica de ejecutar dos programas diferentes en un sistema multitarea; ya sea usando dos terminales distintas o solicitando que se envíe cada instancia del programa a segundo plano. Esta es la estrategia de crear varios procesos, pero tiene varios inconvenientes: la administración de los recursos compartidos es más engorrosa de lo que debería ser y los procesos tienen un contexto relativamente grande; formado por su propio heap, su propio stack, sus propias variables, etc, lo que hace que su construcción y administración sea también relativamente lenta.

La otra estrategia; y la más apropiada para muchos de los problemas, es usar hilos: un solo proceso que realiza varias tareas a la vez (como hemos expuesto anteriormente). Además; los hilos al ser parte de un proceso, no requieren de una inicialización tan elaborada y su ejecución y mantenimiento es más eficiente. Volviendo a Java; puesto que es un lenguaje orientado a objetos, no debería sorprendernos que los hilos los modele como objetos. Se representan con la clase java.lang.Thread y como puede suponer; al ser parte de java.lang, están presente en todos los programas de Java (recordemos que todo proceso -programa- debe tener al menos un hilo). Thread nos permite acceder al hilo sobre el que se estemos ejecutando, crear hilos nuevos, mantener un grupo de ellos (conocidos como thread pools), terminar un hilo; entre otras. Thread es una clase concreta, y por lo mismo ya tiene definidos todos sus métodos y variables con los que trabaja… Entonces; ¿como es que podemos usar hilos para hacer lo que nosotros queramos, si ya están definidos? Afortunadamente y a diferencia de java.lang.Integer o java.lang.String, Thread no es una clase final y podemos extenderla (heredar de ella). Además, los hilos en Java son definidos por la interfaz java.lang.Runnable (Thread implementa esta interfaz) que también podemos usar para crear nuestras operaciones concurrentes. Runnable define un único método llamado run; no devuelve ni recibe nada y su firma es la siguiente: void run();

Las instrucciones de run es lo que Java ejecuta concurrentemente en nuestros hilos. Así; tenemos dos formas (principales) de crear hilos: ● Extendiendo a Thread y sobreescribiendo el método run en nuestra nueva clase. ● Implementando a Runnable y pasar nuestra clase a un Thread para que ejecute su método run (a continuación veremos esto con más detalle). Es importante mencionar que fuera de pequeños experimentos, es recomendado no instanciar hilos mediante el constructor de Thread, ya que Java nos proporciona alternativas mucho más eficientes; como veremos más adelante. Con lo anterior establecido, veamos algunas de las operaciones más utilizadas con hilos en Java. Constructor Thread define un constructor por omisión; que es suficiente para pequeños ejemplos y experimentos, pero no recomendado para programas más serios. El hilo construido con cualquiera de los constructores, estará listo para ejecutar su método run de forma concurrente. Podemos pasarle al constructor una cadena para que el hilo la use como su nombre. Este es arbitrario y nos debería ayudar a identificarlo de los demás hilos en ejecución en nuestra aplicación (es decir, deberíamos evitar nombrar a nuestros hilos patito1… A menos que el hilo represente a un pato de entre un grupo de patos). Otro constructor, toma como argumento una instancia de Runnable. Este hilo en lugar de ejecutar su propio método run, ejecutará el del Runnable dado. También podemos pasarle la cadena adicional para nombrar el hilo. Además, podemos indicar al constructor una referencia al grupo de hilos al que pertenecerá el mismo.

Los grupos de hilos son un objeto modelado por la clase java.lang.ThreadGroup y es importante no confundirlos con los thread pools; modelados por otra clase que veremos más adelante. ThreadGroup nos permite agrupar varios hilos y obtener información general sobre todos ellos. La idea es que los hilos agrupados realicen algún tipo de tarea en común. Esto es diferente a la filosofía de los thread pools, que preparan recursos para la inicialización y ejecución de hilos de forma más eficiente. Demonios El primer método; además de los constructores, que señalaremos de la clase Thread, es el setter void setDaemon(boolean). Con esta instrucción podemos especificarle a Java que el hilo en cuestión deberá ser tratado como un demonio (al pasarle un true. Por omisión es falso). Los demonios son hilos que por alguna razón queremos que continúen ejecutándose aún cuando la aplicación termina: termina el proceso de la JVM junto con nuestra aplicación, pero los demonios pueden seguirse ejecutando. Normalmente los demonios ofrecen algún tipo de servicio. Por ejemplo, si nuestra aplicación es un reloj temporizador de segundo plano, podemos usar un demonio que duerma tanto tiempo como el tiempo que se quiere esperar hasta ejecutar algún evento. Podemos tener demonios que esperan por algún mensaje de red para implementar mensajeros instantáneos, etc. Prioridades Además de setDaemon; Thread define otro setter que puede ser de gran utilidad en algunas aplicaciones, este es void setPriority(int). Los hilos en java son de usuario: la administración de su ejecución es realizada por la máquina virtual. La JVM usa prioridades para calendarizar los hilos; cuyo rango va de Thread.MIN_PRIORITY a Thread.MAX_PRIORITY. Entre más cercano sea el valor de la prioridad de un hilo a MAX_PRIORITY, mayor será la prioridad de ejecución que le otorgará la JVM. Cambio del estado de un hilo: Sleep, notify y wait Otra de las instrucciones importantes para usar es static void Thread.sleep(long). Como su nombre sugiere, pone a dormir un hilo. El parámetro que lleva, es la cantidad de tiempo en milisegundos que dormirá el hilo. Este lapso de tiempo suele ser bastante preciso, por lo que podemos asumir los tiempos de sueño para crear esperas entre hilos (no ocurrirá que los hilos duerman 5 minutos más). Mientras un hilo duerme no ejecuta ninguna instrucción; está detenido. Al despertarlo, reanuda su ejecución en la instrucción que siga a la instrucción que lo durmió (sleep). Podemos despertar al hilo mientras duerme sin importar que todavía le quede tiempo de sueño. Para ello usamos el método de la clase java.lang.Object void notify(). Object define algunos métodos que nos permiten detener y reanudar el hilo sobre el que se ejecute el objeto en el que se haga la llamada. Con lo anterior dicho, es importante mencionar que el método void Object.wait() es similar a Thread.sleep(), pero no especifica cuándo debe despertar el hilo; y a menos que se llame a notify() posteriormente, el hilo nunca despertará.

Es importante considerar que cuando despertamos un hilo con notify; se dispara una excepción llamada InterruptedException. A lo largo del curso, nos encontraremos con problemas que involucran esperar a otros hilos. Cuando forzamos la terminación de una espera de un hilo también dispara una InterruptedException. Terminación de hilos Finalmente, tenemos void Thread.join(). Este método termina el hilo y libera los recursos que estuviera ocupando. Puesto que el hilo podría haber sido interrumpido al solicitar su destrucción, join puede arrojar una InterruptedException. Una estrategia para terminar hilos en Java con esto en consideración, es la siguiente: boolean retry = true; while(retry) { try { thread.join(); retry = false; } catch(InterruptedException e) { Logger.getLogger(“Mi-app”) .log(Level.INFO, “El hilo fue interrumpido”, e); } }

A pesar de consistir en un ciclo, esto debería tomar muy poco tiempo; un par de iteraciones. Si el programa intenta terminar un hilo y no puede hacerlo en menos de 10 iteraciones, lo más probable es que haya algún problema en el diseño de la concurrencia de la aplicación. Intentar terminar un hilo que ejecuta un ciclo while cuya condición de permanencia sigue siendo verdadera hasta este punto, resultará en un fallo: no podemos terminar hilos que no hayan terminado de ejecutar su método run. Por lo anterior, también hay que considerar que si el hilo a terminar está realizando alguna operación larga, como acceso a red o a disco; lo mejor es implementar alguna forma de saber cuando termine dicha operación y entonces solicitar su destrucción. Inicialización del hilo Por cierto, ¿ha notado que run no aparece en la lista anterior? Esto es porque nunca deberemos llamar a run directamente. De hacerlo, se ejecutará el método en el mismo hilo que en el que se hizo la llamada en lugar de hacerlo concurrentemente. Para ejecutar las instrucciones de run apropiadamente usamos void Thread.start(). La palabra reservada synchronized Ya hemos mencionado que los hilos se ejecutan concurrentemente y que comparten las variables globales del programa. Los hilos pueden compartir otras cosas además de variables globales y en general se denominan recursos compartidos a aquellos recursos del sistema a los que la aplicación a la que tiene acceso por medio de más de un hilo (o proceso). Sin embargo, muchas veces vamos a querer organizar y restringir la manera en la que los hilos interactúan con los recursos compartidos. Piense en el siguiente ejemplo: un programa cuenta con dos hilos; uno realiza operaciones aritméticas y produce un resultado cada un cierto tiempo no constante, y almacena el resultado en una variable compartida numérica. El otro hilo le muestra al usuario los resultados que produce el primer hilo; ¿como organizamos

la ejecución de estos hilos para que el segundo evite mostrar resultados no actualizados? ¿como los sincronizamos? A lo largo del curso, estudiaremos diversas estrategias y técnicas para resolver este tipo de problemas y otros más; pero por ahora vamos a conocer uno de los mecanismos más simples (desde el punto de vista del programador) que ofrece Java para sincronizar aplicaciones concurrentes. Para sincronizar varios hilos, es muy común usar “candados”. Estos candados se asocian a los recursos compartidos, de forma que si están abiertos; el primer hilo que quiera apropiarse del recurso, cierra el candado y obliga a esperar a todos los demás hilos que quieran usar el recurso. Hasta que el hilo que cerró el candado lo vuelva a abrir, alguno de los otros hilos podrá intentar apropiarselo para realizar sus tareas. Veremos a lo largo de este curso que este problema no es trivial: bajo la solución expuesta no hay orden en quien se apropia de los recursos y en sistemas multi-procesador; dos o más hilos pueden ser los primeros en cerrar simultáneamente el candado. En Java, todos los objetos cuentan con un candado (tentativamente cualquier objeto de Java puede ser un recurso compartido). La palabra reservada de Java synchronized, tiene dos sintaxis válidas (que nos ayudan a resolver bajo diferentes escenarios, el mismo problema): ● Podemos usarla en la firma de un método después de la declaración de acceso (public, private, protected...) y antes del tipo de datos del retorno (void, int, Object); por ejemplo: public synchronized int metodo() { … } En este caso; cuando los hilos intenten ejecutar el método síncrono, van a competir por apropiarse del candado del objeto al que se le solicita ejecutar el método síncrono (Java resuelve los problemas mencionados anteriormente y garantiza exclusión mutua). Tome en cuenta que el candado es por objeto, por lo que si tenemos dos instancias de la misma clase con el método sincronizado, y un hilo solicita la ejecución del método en una de las instancias y otro hilo ejecuta el método en la otra instancia; el método será ejecutado por ambos hilos en ambas instancias, sin importar el estado de los candados entre ellos (porque son objetos diferentes). Cuando el hilo que haya ejecutado el método síncrono termine de hacerlo, abre el candado y le da oportunidad al resto de los hilos de ejecutar el método. Es importante tomar en cuenta que por “hilo” no nos referimos exclusivamente a una instancia de Thread; si no a cualquier objeto que ejecute sus instrucciones en algún hilo de ejecución que pertenezca al programa. ●

Podemos usarla para definir un bloque de código sincronizado. Esta sintaxis requiere del recurso compartido (algún objeto) que queremos manipular de forma excluyente entre los hilos; por ejemplo: synchronized(unObjeto) { /* * este bloque de código es el sincronizado * y Java garantiza exclusión mutua en él */ }

Un último detalle que es importante tomar en cuenta sobre synchronized, es que al manejar candados por objeto; cuando un hilo ejecuta un bloque de código síncrono, se apropia del candado de dicho objeto y los demás hilos no sólo no podrán ejecutar simultáneamente ese bloque de código síncrono particular; sino también ninguno otro que defina el mismo objeto que se encuentre bloqueado. Ejercicio. Revise el ejemplo “calendarizador en java” y observe la forma en la que varios hilos realizan distintas operaciones por turnos de forma simultánea. Thread pools (Grupos de hilos) Los grupos de hilos son un tipo de objetos que tienen una colección de hilos listos para ejecutarse. Son la forma preferida de crear hilos. Podemos crear hilos y grupos de hilos mediante la clase java.util.concurrent.Executors; usando los métodos: ● newSingleThreadExecutor() - Devuelve uno y solo un hilo nuevo para realizar tareas de segundo plano. ● newFixedThreadPool(int) - Crea un grupo de hilos con exactamente tantos hilos listos para ejecutarse como se le indique en su parámetro. ● newCachedThreadPool() - Crea un grupo de hilos dinámico; es un poco menos eficiente que el de tamaño fijo, pero es útil cuando no hay certeza del número de hilos que va a necesitar nuestra aplicación (por ejemplo si es un servidor remoto). Ahora bien, estos tres métodos (y muchos otros definidos en Executors) no devuelven objetos (o colecciones) de la clase Thread o Runnable; sino más bien devuelven una instancia de la clase java.util.concurrent.ExecutorService Esta clase es la que se encarga de ejecutar los hilos previamente preparados de forma eficiente; y lo hace a través del método execute(Runnable). Define algunos otros métodos que nos permiten un mayor control e interacción con los resultados de los hilos en ejecución con los que contemos; pero este será suficiente la mayor parte de las veces. Otro método importante en ExecutorService es shutdown(). Este método interrumpe y termina la ejecución de cualquier tarea que se le haya solicitado. Callable y Future Antes de retomar el uso de hilos en las GUI, vamos a conocer un par de formas más de crear tareas concurrentes. La primera de ellas es a través de la interfaz java.util.concurrent.Callable Callable es muy similar a Runnable; excepto porque el método que define (llamado call y no run) regresa un valor de tipo V, a diferencia de run que no devuelve nada. Además, call puede disparar una excepción. java.util.concurrent.Future es una interfaz que nos permite definir acciones mientras y al final de la ejecución de tareas concurrentes. También puede ayudarles a ser interrumpidas en caso de ser necesario. Retomando el problema de la interfaz gráfica irresponsiva Ahora conociendo los hilos en Java, podemos pensar en evitar obstruir el flujo del método que responde a los eventos en el botón “Iniciar”. Quizá una primera idea para solucionar el problema sea que el método instancie un hilo que contiene en su método run las instrucciones de incrementar el contador y actualizar el texto.

Pero, ¿cómo hacemos que interactúe con el botón “detener”? Quizá lo más fácil sea contar con una variable booleana global en el programa (recuerde que por omisión, todas las variables globales de un programa son públicas para todos sus hilos). Al generar un evento en “iniciar”, le asignamos un valor falso a la variable, e iteramos la cuenta mientras el valor de dicha variable no cambie. Así, al generar un evento en “detener”, lo único que tendríamos que hacer es justamente asignar el valor verdadero a la misma variable compartida. Ejercicio. Modifique el ejemplo “Interfaz no responsiva” de acuerdo a las ideas anteriores y ejecute el programa. ¿el comportamiento de la aplicación es el esperado? ¿qué pasa con los tiempos de respuesta? Veamos algunas herramientas que nos proporciona Swing, para poder hacer una última mejora a nuestro programa que nos permitirá aprovechar mejor los recursos del sistema. Hilos y Swing Toda aplicación que use Swing contará con al menos tres hilos: 1. Hilo principal, construido por la JVM cuando es invocado el programa para ejecutar el main de nuestra aplicación. Este usualmente solo construye la interfaz gráfica y muere; pero podríamos conservarlo para otras tareas, dependiendo del diseño de nuestra aplicación. 2. Hilo administrador de eventos. Este es el encargado de refrescar la memoria de vídeo y de administrar eventos; de forma que la entrada y salida de la aplicación (al menos en lo que compete a la GUI) sea responsiva. Este hilo es el que ejecuta por defecto todas las operaciones de los métodos receptores de eventos. 3. Hilos trabajadores de segundo plano, que se encargan de tareas de cómputo intensivo e IO. Por otro lado, la clase javax.swing.SwingUtilities contiene un par métodos estáticos de interés para lo que estamos haciendo: static void invokeLater(Runnable) y static void invokeAndWait(Runnable); que nos permite encolar los Runnables dados para ejecutar su método run dentro del hilo de eventos de swing. La diferencia entre invokeLater e invokeAndWait, es que invokeAndWait espera a que el hilo de eventos termine de ejecutar todo lo que tenga pendiente (en la iteración en la que se encuentre), para al final ejecutar el método run del Runnable dado. Es muy recomendable usar invokeLater en el hilo principal de nuestro programa para construir la interfaz gráfica. Ya para terminar, conoceremos a la clase javax.swing.SwingWorker; que nos permite administrar los hilos de segundo plano en una aplicación gráfica. Como hemos visto en el ejemplo de la interfaz no responsiva original; ejecutar código que requiera una fracción considerable de tiempo en terminar en el hilo de eventos, es una mala estrategia porque da la apariencia de que la aplicación se ha congelado.

Un SwingWorker es básicamente un hilo de ejecución que realiza tareas que toman mucho tiempo en ejecutarse en segundo plano y devuelve los resultados al hilo de eventos para que puedan reflejarse en la interfaz gráfica (recordemos que este último hilo es el encargado de actualizar la memoria de vídeo). Sin embargo, su capacidad no se limita a devolver los resultados al final de la ejecución; puede devolver también resultados parciales que podemos usar para mostrarle al usuario los avances en pantalla. SwingWorker es una clase que ocupa un par de tipos de datos parametrizados: T y V. T es el tipo de datos que se le asociará a el resultado final de ejecutar las tareas del SwingWorker y V es el tipo de datos que se asocia a los resultados parciales. SwingWorker es una clase abstracta y para usarla necesitamos definir únicamente el método protected T doInBackground(); que debe contener el código de la tarea larga que queremos que realice el hilo de segundo plano. Además, define varios otros métodos que podemos usar para conocer la interacción del usuario con el sistema. Es recomendable que las tareas de cómputo intensivo en el método doInBackground() se realicen iterativamente en un ciclo que se repita mientras el usuario no desee interrumpir la tarea; para ello podemos apoyarnos del método isCancelled() como condición de permanencia. Al final del ciclo es útil pasarle los resultados parciales del procesamiento al método publish(V...), para exhibirlos al usuario. Es importante tomar en cuenta que la publicación es asíncrona. SwingWorker no sabe qué hacer por omisión con nuestros resultados parciales (ni con el general), por lo que nos permite redefinir el método protected void process(java.util.List). La lista que recibe process como argumento, contendrá todos los resultados parciales que se hayan acomulado durante un tiempo mientras se ejecuta doInBackground (recordemos que estas publicaciones son asíncronas). Usando esta lista podemos modificar elementos en la interfaz para reflejar el progreso. Es importante considerar que cada vez que se invoca process, los resultados parciales que se hayan recibido la última vez que se invocó process ya no estarán disponibles en la lista. Finalmente; para actualizar la interfaz gráfica y reflejar los resultados generales de la ejecución del SwingWorker, podemos sobreescribir el método protected void done(). Será importante tomar en cuenta que done se ejecuta en el hilo de eventos de Swing, por lo que debe ser breve o podría crear retrasos en la interfaz. Ejercicio. Vuelva a modificar el ejemplo “Interfaz no responsiva”. Agregue una pequeña espera (retraso) en el ciclo que cuenta y actualiza la etiqueta y termine el hilo al final del método que atiende los eventos del botón “detener”. Analice y considere usar la la clase SwingUtilities o SwingWorker para optimizar modificar la forma en la que se instancia el hilo que realiza el conteo. Referencias 1. Hock Chuan, C., (2008), “Java Programming Tutorial: Multithreading & concurrent programming” en Nanyang Technological University. [En línea]. Singapur, disponible en: https://www3.ntu.edu.sg/home/ehchua/programming/java/J5e_multithreading.html

2. Oracle Corporation, “Java platform, standard edition 7. API specification” en Oracle Help Center. [En línea]. EE UU, disponible en: https://docs.oracle.com/javase/7/docs/api/ [Accesado el día 16 de agosto del 2016].