2. Pourquoi étudier les systèmes d'exploitation?
2.1 Voir sous les abstractions
Un programme moderne s'appuie sur plusieurs couches : langage, bibliothèque standard, environnement d'exécution, système d'exploitation, pilotes et matériel. Ces couches augmentent la productivité, mais elles cachent aussi des coûts et des contraintes.
Une opération apparemment simple peut entraîner :
- un appel système et une transition de privilège;
- une ou plusieurs copies de données;
- une attente d'entrée-sortie;
- le blocage d'un processus;
- un changement de contexte;
- une traduction d'adresse virtuelle;
- un accès à un périphérique beaucoup plus lent que le processeur.
Comprendre ces mécanismes permet de diagnostiquer des problèmes de performance, de choisir un modèle de concurrence adapté, de réduire des opérations coûteuses et de comprendre pourquoi un programme peut fonctionner différemment selon la charge ou l'ordonnancement.
2.2 Les erreurs temporelles sont difficiles
Une condition de concurrence apparaît lorsque le résultat dépend de l'ordre non contrôlé dans lequel plusieurs exécutions accèdent à des données partagées. Ces erreurs peuvent être rares, disparaître pendant le débogage et ne se manifester que sous certaines vitesses d'exécution.
L'étude des systèmes d'exploitation prépare à reconnaître ces problèmes et à utiliser correctement les mécanismes de synchronisation : mutex, sémaphores, variables de condition et protocoles d'accès aux sections critiques.
2.3 Therac-25 : une erreur logicielle peut devenir physique
Le cas du Therac-25, une machine de radiothérapie utilisée dans les années 1980, illustre les conséquences possibles d'une gestion défectueuse de l'état partagé. Une variable participait à la fois au traitement des commandes saisies et au suivi de la position d'un mécanisme. Des opérateurs expérimentés pouvaient entrer certaines séquences assez rapidement pour provoquer un état incohérent. Des patients ont subi des surdoses de radiation.
Les leçons importantes sont générales :
- un programme qui contrôle du matériel peut causer des dommages physiques;
- une commande envoyée n'est pas une preuve que l'équipement se trouve réellement dans l'état attendu;
- un état partagé exige un protocole de synchronisation explicite;
- les scénarios rares et dépendants du temps doivent être considérés dès la conception;
- les mécanismes de protection ne sont pas de simples optimisations.