US

Scheduler

Maintenant qu'on a vu les différents états possible pour un thread, on va pouvoir mieux comprendre pourquoi on distingue les états Runnable et Running. Le but des threads est de pouvoir être exécutés en parallèle, mais pour cela, il faut bien entendu autant de machines ou de processeurs qu'il y a de threads à exécuter, ce qui n'est pas toujours possible. Que se passe-t-il alors ? La machine virtuelle Java possède un scheduler (ou ordonnanceur en français) de thread qui va faire en sorte de répartir les ressources processeurs le plus équitablement possible entre les différents threads.

Fonctionnement

Voyons en gros le fonctionnement d'un scheduler. Une vue globale vous est montrée sur la figure suivante. On peut y voir trois éléments : un pool de thread, le scheduler et les processeurs.

Fonctionnement d'un scheduler
Figure 1.5 Fonctionnement d'un scheduler.

Supposons que l'on dispose de n processeurs. À tout moment, il peut y avoir au maximum n threads qui sont dans l'état Running. Tous les autres threads qui sont prêts à être exécutés se trouvent dans l'état Runnable et sont stockés dans le pool de threads. Le boulot du scheduler est de faire bouger les threads entre le pool de threads et les processeurs et vice-versa, afin de garantir que tout thread qui peut l'être sera exécuté.

Une version naive d'algorithme de scheduling consiste à garder, pour chaque thread, le moment où il a pu sortir du pool de threads vers un processeur. On fixe ensuite une limite de temps par thread, et une fois ce dernier écoulé, on ramène le thread dans le pool et on sélectionne un autre à envoyer vers le processeur ainsi libéré. On ne va pas entrer dans les détails des techniques d'ordonnancement, mais cette solution n'est pas très intéressante en général.

Exemple

Voyons un exemple concret grâce auquel vous allez pouvoir observer qu'il y a bel et bien un scheduler. La classe suivante représente un thread qui effectue un décompte de 3 à 1.