Processus et interblocages

Un programme est une description d’instructions enregistrées dans un fichier ou conservées sous une autre forme. Un processus est une instance de son exécution. Lancer deux fois le même programme peut créer deux processus distincts, avec des données de travail différentes. Le texte du programme ne décrit donc pas à lui seul l’état complet de chaque exécution. Une application complexe peut également employer plusieurs processus coopérant entre eux.

Lors de la création d’un processus, le système prépare un contexte d’exécution : zones de mémoire, registres, position dans le programme et ressources associées. Il lui attribue un identifiant de processus, appelé PID. Cet identifiant distingue les processus présents ; il peut être réutilisé après la fin d’un ancien processus. Dans les systèmes de type Unix, une relation parent-enfant aide à suivre leur création. Les détails des mécanismes de lancement dépendent du système.

Le système d’exploitation gère le chargement, les entrées-sorties et le partage des ressources. Il évite qu’un programme s’attribue librement tout le matériel. Les protections de mémoire organisent notamment l’isolation entre processus, tandis que des mécanismes contrôlés autorisent des communications. Il ne faut donc pas interpréter isolé comme incapable d’échanger, ni programme en mémoire comme processus actuellement exécuté sur un cœur.

Un processus prêt dispose des conditions nécessaires pour être exécuté mais attend un accès au processeur. Un processus élu est actuellement exécuté sur un cœur. Un processus bloqué attend un événement ou une ressource, par exemple la fin d’une entrée-sortie. Lorsqu’une opération attendue se termine, il peut redevenir prêt. Il ne devient pas nécessairement immédiatement élu : d’autres processus peuvent aussi attendre le processeur.

Un processus élu peut être interrompu par le système, qui sauvegarde son contexte et en sélectionne un autre. Le premier redevient prêt s’il peut continuer. S’il demande une ressource indisponible, il devient bloqué. S’il termine son travail, il sort de l’exécution active ; le système récupère ses ressources selon ses règles. Le vocabulaire des outils réels peut détailler davantage ces états, notamment sous Unix.

Sur un seul cœur, plusieurs processus peuvent progresser pendant la même période grâce à l’alternance. Cela constitue une exécution concurrente. Un parallélisme matériel permet des exécutions réellement simultanées sur plusieurs unités de calcul. La concurrence existe aussi sur une machine multicœur : certains processus restent en attente et plusieurs exécutions partagent des ressources. La présence de plusieurs cœurs n’élimine donc pas les problèmes de coordination.

Pour observer un processus sur un système de type Unix, la commande ps peut afficher un instantané. Avec son identifiant numérique, ps -p PID -o pid,ppid,stat,comm demande le PID, l’identifiant du parent, un code d’état et le nom du programme. PID doit être remplacé par un identifiant réellement observé. Cette commande ne demande pas d’arrêter le programme. Les codes exacts sont décrits par la documentation de la version utilisée ; un instantané n’atteste pas l’activité de toute la journée.

L’ordonnanceur choisit parmi les processus prêts celui qui utilisera le processeur. Il applique une politique pouvant prendre en compte des priorités, le temps déjà utilisé et les attentes. Dans un modèle de tourniquet, chaque processus prêt reçoit au maximum une tranche de temps appelée quantum, puis retourne en fin de file s’il n’a pas terminé et reste prêt. Un processus bloqué ne doit pas consommer son tour comme s’il pouvait calculer.

Un quantum très court multiplie les changements de contexte ; un quantum long peut augmenter l’attente avant la prochaine reprise. Un tourniquet simple favorise le partage, mais ne garantit pas à lui seul toutes les propriétés de temps de réponse d’un système réel. Pour une simulation, la règle d’arrivée dans la file, les durées et les éventuels événements simultanés doivent être connus. Sinon plusieurs chronologies peuvent correspondre à des hypothèses différentes.

Une ressource exclusive ne peut être attribuée qu’à un utilisateur à la fois dans notre modèle : un verrou ou un équipement indivisible en sont des exemples. Attendre une telle ressource est normal lorsque son détenteur peut finir puis la libérer. Un interblocage, ou deadlock, apparaît lorsque des processus restent enfermés dans une attente dont aucun des participants ne peut sortir selon les règles prévues. Ce n’est pas seulement une tâche lente.

Le scénario de la figure suffit à expliquer le blocage : P1 ne libérera R1 qu’après avoir obtenu R2, et P2 ne libérera R2 qu’après avoir obtenu R1. Chaque ressource est unique et personne ne peut la retirer de force à son détenteur dans ce modèle. Chacun attend donc une action que l’autre ne pourra pas effectuer. Accorder davantage de temps processeur ne rend aucune ressource disponible.

Pour raisonner, dessine des flèches de demande des processus vers les ressources attendues et des flèches d’attribution des ressources vers leurs détenteurs. Un cycle met en évidence la dépendance circulaire. La conclusion dépend toutefois des hypothèses : avec plusieurs exemplaires d’une ressource ou la possibilité d’une libération indépendante, un dessin cyclique ne suffit pas toujours à prouver un interblocage. On explicite ici un exemplaire et une attente conservant les ressources déjà détenues.

S’entraîner : consulte la rubrique Exercices du site. La prochaine leçon aborde un autre partage de ressources : le chemin des paquets entre les routeurs.