11. Choisir quand détecter et comment reprendre
11.1. Fréquence et surcharge de gestion
Un détecteur consomme du temps processeur. Le cours rapproche cette charge de celle des changements de contexte : il s'agit de gestion du système, qui utilise du temps sans exécuter directement le travail des programmes utilisateurs.
| Déclenchement | Intérêt | Coût ou limite |
|---|---|---|
| À chaque allocation | Réagir très fréquemment aux changements d'état | Ajouter fréquemment le coût de l'analyse et ralentir l'exécution |
| À intervalle fixe, par exemple cinq minutes | Espacer les analyses et laisser les processus s'exécuter entre deux passages | Un interblocage apparu après un passage peut attendre le suivant avant d'être détecté |
| Selon une heuristique, par exemple une utilisation CPU sous un seuil | Déclencher une analyse lorsque l'état paraît suspect | Choisir un seuil adapté; l'indicateur ne constitue pas le diagnostic |
Il n'y a pas de fréquence unique imposée pour tous les systèmes. Le choix dépend des processus exécutés, du coût de la détection et du délai de réaction acceptable. Un contrôle périodique espace la charge, mais ne transforme pas automatiquement l'intervalle choisi en durée garantie de réparation : il faut encore détecter puis reprendre.
11.2. Utilisation CPU et mention du livelock
Si beaucoup de processus attendent des ressources, la charge utile sur le CPU peut diminuer. Cette baisse peut donc être un indice qui justifie de lancer un détecteur. Elle ne prouve pas à elle seule une dépendance circulaire : la conclusion doit encore provenir de l'analyse des ressources et des attentes.
Le support et l'oral mentionnent aussi le livelock, sans en développer ici un mécanisme ou un algorithme complet. Le point à retenir dans cette limite est qu'activité et progression utile ne sont pas interchangeables. Aucune description détaillée d'un sujet annoncé pour plus tard n'est ajoutée à la place des sources.
11.3. Préempter une ressource
La détection établit que le problème existe; elle ne remet pas automatiquement les processus en marche. Une première récupération consiste à retirer une ressource pour casser une dépendance et permettre une autre progression.
Le retrait peut endommager l'opération en cours. Une impression peut être interrompue ou mélangée avec une autre; une gravure de CD interrompue peut rendre le disque inutilisable. La possibilité de retirer techniquement la ressource ne signifie donc pas que ce retrait est acceptable pour l'application.
La décision dépend du contexte et des conséquences tolérables. Il faut identifier ce qui est retiré, quelle dépendance est affectée et quels effets de l'opération initiale subsistent.
11.4. Revenir à un point de reprise
Le rollback suppose que l'exécution ait enregistré des points de reprise. On revient à un état antérieur pour continuer depuis ce point. Cet état doit conserver les variables et les autres informations nécessaires à une reprise cohérente : retenir seulement une position dans le programme ne suffit pas.
Les opérations rejouées peuvent avoir des effets qui dépassent cet état sauvegardé. Une action déjà effectuée sur des données externes pourrait être répétée une deuxième fois si la restauration ne la prend pas correctement en compte. Le cours insiste donc sur la compatibilité de la reprise avec les opérations réellement exécutées.
L'intérêt du point de reprise est de permettre un retour contrôlé, mais sa simple existence ne garantit pas l'absence de conséquences. Il faut savoir quel état a été enregistré et quels effets doivent également être restaurés ou traités.
11.5. Interrompre ou supprimer un processus
Une autre approche consiste à arrêter un processus pour récupérer ses ressources. La décision doit viser les dépendances qui entretiennent le problème. Le support évoque des processus dans le cycle ou hors de celui-ci; l'oral indique que l'effet d'une intervention extérieure peut être moindre et que casser le cycle est l'objectif.
Il ne faut pas supposer qu'interrompre n'importe quel processus, ou simplement le suspendre en lui laissant ses allocations, libère automatiquement la ressource attendue. L'effet utile recherché est une libération ou une modification effective des dépendances. La procédure concrète dépend donc de ce que l'arrêt produit dans le système considéré.
Le choix de la victime tient aussi compte du redémarrage. Un compilateur que l'on peut relancer depuis le début est généralement moins coûteux à interrompre qu'un programme ayant déjà modifié une base de données. Relancer ce dernier pourrait refaire une opération, par exemple incrémenter à nouveau une valeur déjà mise à jour. Récupérer une ressource ne suffit pas si le résultat applicatif devient incorrect.
11.6. Portée des solutions de reprise
Les trois approches ont un coût : dommage à l'opération en cours, nécessité d'un état sauvegardé cohérent, perte de travail ou risque de répéter des effets. Aucune n'est présentée comme une réparation universelle satisfaisante dans tous les cas.
L'enseignant précise que l'accent de cette séance porte surtout sur la détection. Pour l'étude, il faut pouvoir exécuter les deux détecteurs et expliquer les principes et conséquences des reprises, sans attribuer à cette introduction des garanties ou protocoles qui n'y sont pas développés.