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.

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.