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:
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.
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.
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.
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 = 400000Esto 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 = 400000Esto 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?