## La Prioridad de un Thread

Anteriormente en esta lección , hemos reclamado que los applets se ejecuten de forma concurrente. Mientras conceptualmente esto es cierto, en la práctica no lo es. La mayoría de las configuraciones de ordenadores sólo tienen una CPU, por eso los threads realmente se ejecutan de uno en uno de forma que proporcionan una ilusión de concurrencia. La ejecución de varios threads en una sola CPU, en algunos órdenes, es llamada programación. El sistema de ejecución de Java soporta un algoritmo de programación deterministico muy sencillo conocido como programación de prioridad fija.Este algoritmo programa los threads basándose en su prioridad relativa a otros threads "Ejecutables".

Cuando se crea un thread Java, hereda su prioridad desde el thread que lo ha creado. También se puede modificar la prioridad de un thread en cualquier momento después de su creacción utilizando el método setPriority(). Las prioridades de un thread son un rango de enteros entre MIN_PRIORITY y MAX_PRIORITY (constantes definidas en la clase Thread). El entero más alto, es la prioridad más alta. En un momento dado, cuando varios threads está listos para ser ejecutados, el sistema de ejecución elige aquellos thread "Ejecutables" con la prioridad más alta para su ejecución. Sólo cuando el thread se para, abandona o se convierte en "No Ejecutable" por alguna razón empezará su ejecución un thread con prioridad inferior. Si dos threads con la misma prioridad están esperando por la CPU, el programador elige uno de ellos en una forma de competición. El thread elegido se ejecutará hasta que ocurra alguna de las siguientes condiciones:

- Un thread con prioridad superior se vuelve "Ejecutable".
- Abandona, o su método run() sale.
- En sistemas que soportan tiempo-compartido, su tiempo ha expirado.

Luego el segundo thread tiene una oprtunidad para ejecutarse, y así continuamente hasta que el interprete abandone.

El algoritmo de programación de threads del sistema de ejecución de Java también es preemptivo. Si en cualquier momento un thread con prioridad superior que todos los demás se vuelve "Ejecutable", el sistema elige el nuevo thread con prioridad más alta. Se dice que el thread con prioridad superior prevalece sobre los otros threads.

Regla del Pulgar: En un momento dado, el thread con prioridad superior se está ejecutando. Sin embargo, este no es una garantía. El programador de threads podría elegir otro thread con prioridad inferior para evitar el hambre. Por esta razón, el uso de las prioridades sólo afecta a la politica del programador para propósitos de eficiencia. No dependas de la prioridad de los threads para algoritmos incorrectos.

### La carrera de Threads

> Este código fuente Java implementa un applet que anima una carrera entre dos threads "corredores" con diferentes prioridades. Cuando pulses con el ratón sobre el applet, arrancan los dos corredores. El corredor superior , llamado "2", tiene una prioridad 2. El segundo corredor, llamado "3", tiene una prioridad 3.

> Prueba esto: Pulsa sobre el applet inferior para iniciar la carrera.

> Este es el método run() para los dos corredores.

>     public int tick = 1;
>     public void run() {
>         while (tick < 400000) {
>             tick++;
>         }
>     }

Este método sólo cuenta desde 1 hasta 400.000. La variable tick es pública porque la utiliza el applet para determinar cuanto ha progresado el corredor (cómo de larga es su línea).

Además de los dos threads corredores, el applet tiene un tercer thread que controla el dibujo. El método run() de este thread contiene un bucle infinito; durante cada iteración del bucle dibuja una línea para cada corredor (cuya longitud se calcula mediante la variable tick), y luego duerme durante 10 milisegundos. Este thread tiene una prioridad de 4 -- superior que la de los corredores. Por eso, siempre que se despierte cada 10 milisegundos, se convierte en el thread de mayor prioridad, prevalece sobre el thread que se está ejecutando, y dibuja las líneas. Se puede ver cómo las líneas van atravesando la página.

Como puedes ver, esto no es una carrera justa porque un corredor tiene más prioridad que el otro. Cada vez que el thread que dibuja abandona la CPU para irse a dormir durante 10 milisegundos, el programador elige el thread ejecutable con una prioridad superior; en este caso, siempre será el corredor llamado "3". Aquí tienes otra versión del applet que implementa una carrera justa, esto es, los dos corredores tienen la misma prioridad y tienen las mismas posibilidades para ser elegidos.

Prueba esto: Pulsa sobre el Applet para iniciar la carrera.

En esta carrera, cada vez que el thread de dibujo abandona la CPU, hay dos threads ejecutables con igual prioridad -- los corredores -- esperando por la CPU; el programador debe elegir uno de los threads. En esta situación, el programador elige el siguiente thread en una especie de competición deportiva.

### Threads Egoistas

> La clase Runner utilizada en las carreras anteriores realmente implementea un comportamiendo "socialmente-perjudicioso". Recuerda el método run() de la clase Runner utilizado en las carreras:

>     public int tick = 1;
>     public void run() {
>         while (tick < 400000) {
>             tick++;
>         }
>     }

> El bucle while del método run() está en un método ajustado. Esto es, una vez que el programador elige un thread con este cuerpo de thread para su ejecución, el thread nunca abandona voluntariamente el control de la CPU -- el thread se continúa ejecutando hasta que el bucle while termina naturalmente o hasta que el thread es superado por un thread con prioridad superior.

> En algunas situaciones, tener threads "egoistas" no causa ningún problema porque prevalencen los threads con prioridad superior (como el thread del dibujo prevalece sobres los threads egoistas de los corredores. Sin embargo, en otras situaciones, los threads con métodos run() avariciosos de CPU, como los de la clase Runner, pueden tomar posesión de la CPU haciendo que otros threads esperen por mucho tiempo antes de obtener una oportunidad para ejecutarse.

### Tiempo-Compartido

> En sistemas, como Windows 95, la lucha contra el comportamiento egoista de los threads tiene una estrategia conocida como tiempo-compartido. Esta estrategia entra en juego cuando existen varios threads "Ejecutables" con igual prioridad y estos threads son los que tienen una prioridad mayor de los que están compitiendo por la CPU. Por ejemplo, este programa Java (que está basado en la carrera de Applets anterior) crea dos threads egoistas con la misma prioridad que tienen el siguiente étodo run():

>     public void run() {
>         while (tick < 400000) {
>             tick++;
>             if ((tick % 50000) == 0) {
>                 System.out.println("Thread #" + num + ", tick = " + tick);
>             }
>         }
>     }

> Este método contiene un bucle ajustado que incrementa el entero tick y cada 50.000 ticks imprime el indentificador del thread y su contador tick.

> Cuando se ejecuta el programa en un sistema con tiempo-compartido, verás los mensajes de los dos threads, intermitentemente uno y otro. Como esto:

>     Thread #1, tick = 50000
>     Thread #0, tick = 50000
>     Thread #0, tick = 100000
>     Thread #1, tick = 100000
>     Thread #1, tick = 150000
>     Thread #1, tick = 200000
>     Thread #0, tick = 150000
>     Thread #0, tick = 200000
>     Thread #1, tick = 250000
>     Thread #0, tick = 250000
>     Thread #0, tick = 300000
>     Thread #1, tick = 300000
>     Thread #1, tick = 350000
>     Thread #0, tick = 350000
>     Thread #0, tick = 400000
>     Thread #1, tick = 400000

> Esto es porque un sistema de tiempo compartido divide la CPU en espacios de tiempo e iterativamente le da a cada thread con prioridad superior un espacio de tiempo para ejecutarse. El sistema de tiempo compartido itera a través de los threads con la misma prioridad superior otorgándoles un pequeño espacio de tiempo para que se ejecuten, hasta que uno o más de estos threads finalizan, o hasta que aparezca un thread con prioridad superior. Observa que el tiempo compartido no ofrece garantias sobre la frecuencia y el orden en que se van a ejecutar los threads.

> Cuando ejecutes este programa en un sistema sin tiempo compartido, sin embargo, veras que los mensajes de un thread terminan de imprimierse antes de que el otro tenga una oportunidad de mostrar un sólo mensaje. Como esto:

>     Thread #0, tick = 50000
>     Thread #0, tick = 100000
>     Thread #0, tick = 150000
>     Thread #0, tick = 200000
>     Thread #0, tick = 250000
>     Thread #0, tick = 300000
>     Thread #0, tick = 350000
>     Thread #0, tick = 400000
>     Thread #1, tick = 50000
>     Thread #1, tick = 100000
>     Thread #1, tick = 150000
>     Thread #1, tick = 200000
>     Thread #1, tick = 250000
>     Thread #1, tick = 300000
>     Thread #1, tick = 350000
>     Thread #1, tick = 400000

> Esto es porque el sistema sin tiempo compartido elige uno de los threads con igual prioridad para ejecutarlo y le permite ejecutarse hasta que abandone la CPU o hasta que aparezca un thread con prioridad superior.

> Nota: El sistema de ejecución Java no implementa (y por lo tanto no garantiza) el tiempo compartido. Sin embargo, algunos sistemas en los que se puede ejecutar Java si soportan el tiempo compartido. Los programas Java no deberían ser relativos al tiempo compartido ya que podrían producir resultados diferentes en distintos sistemas.

> Prueba esto: Compila y ejecuta las clases RaceTest y SelfishRunner en tu ordenador. ¿Puedes decir si su sistema tiene tiempo compartido?

> Como te puedes imaginar, escribir código que haga un uso intensivo de la CPU puede tener repercusiones negativas en otros threads que se ejecutan en el mismo proceso. En general, se debería intentar escribir threads con "buen comportamiento" que abandonen voluntariamente la CPU de forma periódica y le den una oportunidad a otros threads para que se ejecuten. En particular, no escribas nunca código Java que trate con tiempo compartido-- esto garantiza prácticamente que tu programa dará diferentes resultados en distintos sistemas de ordenador.

> Un thread puede abandonar la CPU (sin ir a dormir o algún otro método drástico) con una llamada al método yield(). Este método da una oportunidad a otros threads con la misma prioridad. Si no existen otros threads con la misma prioridad en el estado "ejecutable", este método será ignorado.

> Prueba esto: Reescribe la clase SelfishRunner para que sea un PoliteRunner "Corredor Educado" mediante una llamada al método yield() desde el método run(). Asegurese de modificar el programa principal para crear PoliteRunners en vez de SelfishRunners. Compila y ejecuta las nuevas clases en tu ordenador. ¿No está mejor ahora?

### Sumario

- La mayoría de los ordenadores sólo tienen una CPU, los threads deben compartir la CPU con otros threads. La ejecución de varios threas en un sólo CPU, en cualquier orden, se llama programación. El sistema de ejecución Java soporta un algoritmo de programación determinístico que es conocido como programación de prioridad fija.

- A cada thread Java se le da una prioridad numérica entre MIN_PRIORITY y MAX_PRIORITY (constantes definidas en la clase Thread). En un momento dato, cuando varios threads están listos para ejecutarse, el thread con prioridad superior será el elegido para su ejecución. Sólo cuando el thread para o se suspende por alguna razón, se empezará a ejecutar un thread con priporidad inferior.

- La programación de la CPU es totalmente preemptiva. Si un thread con prioridad superior que el que se está ejecutando actualmente necesita ejecutarse, toma inmediatamente posesión del control sobre la CPU.

- El sistema de ejecución de Java no hace abandonar a un thread el control de la CPU por otro thread con la misma prioridad. En otras palabras, el sistema de ejecución de Java no comparte el tiempo. Sin embargo, algunos sistemas si lo soportan por lo que no se debe escribir código que esté relacionado con el tiempo compartido.

- Además, un thread cualquiera, en cualquier momento, puede ceder el control de la CPU llamando al método yield(). Los threads sólo pueden 'prestar' la CPU a otros threads con la misma priorida que él -- intentar cederle la CPU a un thread con prioridad inferior no tendrá ningún efecto.

- Cuando todos los threads "ejecutables" del sistema tienen la misma prioridad, el programador elige a uno de ellos en una especie de orden de competición.

Ozito