Parallélisme et Gestion des Blocages dans les Systèmes

Parbegin / Parend

Parbegin / Parend (souvent traduit par personne apprend dans certains contextes) est une structure permettant d'indiquer le parallélisme, ainsi que le début et la fin d'une exécution en parallèle :

• Une déclaration indiquant que l'exécution séquentielle doit être divisée en plusieurs flux d'exécution en parallèle.

Sa forme générale (selon Dijkstra) est la suivante :

parbegin Proposition1; Proposition2; ... PropositionN parend

Le Mutex

Mutex : se produit lorsque chaque processus partageant des données empêche tous les autres d'y accéder en même temps. Il s'applique lorsqu'un processus accède aux données partagées. Lorsque les processus exécutent des transactions qui ne sont pas en conflit, ils sont autorisés à procéder simultanément.

Les sections critiques

Une section critique survient quand un processus accède à des données partagées. Quand un processus est dans une section critique :

• Tous les autres processus sont exclus de leurs propres sections critiques.
• D'autres processus peuvent poursuivre l'exécution en dehors de leur section critique. Quand un processus quitte sa section critique, un autre processus en attente devrait être autorisé à y entrer.
• Un état d'indemnité spéciale est accordé au processus : il a un accès exclusif aux données partagées, et tous les autres processus requérant l'accès à ces données restent en suspens.
• Un programme ne devrait pas être bloqué dans sa section critique, et les sections critiques doivent être soigneusement codées.
• S'il se termine, volontairement ou non, le système d'exploitation doit libérer le mutex pour faciliter le nettoyage et permettre à d'autres processus d'entrer dans leurs sections critiques.

Deadlock (Impasse)

Le Deadlock (impasse) survient lorsqu'un processus attend un événement particulier qui ne se produira pas. Dans l'impasse d'un système, un ou plusieurs processus se trouvent dans une situation de blocage.

REVENGE : OPTIONS DE LA PROCÉDURE (TÂCHE PRINCIPALE), WAIT (CAS) ; REVENGE FIN ;

L'impasse de la circulation

La norme la plus répandue sur la route est qu'une voiture à un carrefour de quatre routes doit céder le passage à la voiture située à sa droite. Cette règle ne fonctionne que s'il n'y a que deux ou trois voitures au croisement. Par exemple, si seules des voitures venant du nord et de l'ouest arrivent, la voiture du nord attendra que celle de l'ouest passe. Toutefois, si quatre voitures arrivent en même temps, tout le monde s'abstient de s'engager, provoquant une impasse. Si toutes les voitures ignorent les règles et s'engagent, chaque voiture recevra une ressource (un quadrant), mais ne pourra pas continuer car la seconde ressource nécessaire est déjà occupée par une autre voiture. Là encore, il y a une impasse.

Blocage d'un simple appel

De nombreux blocages dans un système d'exploitation surviennent en raison de la gestion normale des ressources allouées (ressources utilisables en série).

• La ressource ne peut être utilisée que par un utilisateur à la fois.
• Chaque processus attend que les autres libèrent une ressource.
• Les ressources détenues ne seront pas libérées tant que l'autre processus n'aura pas libéré la sienne.
• Ce dernier procédé d'utilisation de votre application ne libère pas la ressource retenue jusqu'à ce que l'utilisateur relâche son processus d'appel initial.
• Il existe une attente circulaire.

Détection du blocage et report indéfini

Détection du blocage : consiste à savoir s'il existe un verrou afin d'identifier quels processus et ressources sont impliqués. Tout processus faisant partie d'un cycle est bloqué ; s'il n'y a pas de cycle, le système n'est pas verrouillé.

Un problème connexe : le report indéfini (Starvation). C'est un état du système où un processus attend indéfiniment à cause des décisions de planification de l'affectation des ressources. Elle est causée par la politique de planification des ressources du système.

Pour éviter cela, la mise en œuvre du vieillissement (aging) augmente la priorité d'un processus en attente d'une ressource.

Systèmes de spool (bobine)

Les systèmes de spool sont utilisés pour augmenter la capacité d'exécution du système en dissociant un programme de la lenteur des périphériques de commande. Cependant, ils sont sujets aux impasses.

• Pour accélérer l'exécution, les lignes de sortie sont envoyées vers un dispositif plus rapide, comme un disque dur, où elles sont stockées temporairement avant impression.
• Plusieurs travaux partiellement remplis peuvent se bloquer si l'espace disque est saturé avant la fin des travaux.
• Se remettre d'une telle impasse peut nécessiter un redémarrage du système avec perte des travaux en cours.
• Si le système laisse le contrôle à l'opérateur, une récupération moins radicale consiste à supprimer certains travaux pour libérer de l'espace sur le fichier de spool.
• Lors de la génération du système, on indique la quantité d'espace libre pour le fichier spool.
• Pour réduire la probabilité de blocage, on peut fournir un espace disque bien plus grand que nécessaire.
• Une solution courante est de limiter les spoolers : ne plus accepter de nouveaux travaux quand les fichiers sont saturés à 75 %.
• Cela peut réduire la capacité du régime, mais c'est le prix à payer pour réduire la probabilité de blocages.
• Les systèmes actuels sont plus sophistiqués : ils permettent de commencer l'impression avant la fin d'un travail ou d'allouer l'espace de manière dynamique.

Les quatre conditions de blocage

Coffman, Elphick et Shoshani ont défini quatre conditions nécessaires pour produire une impasse :

• Le processus revendique le contrôle exclusif des ressources demandées (condition d'exclusion mutuelle).
• Les processus maintiennent les ressources allouées tout en attendant des ressources supplémentaires (condition d'attente).
• Les ressources ne peuvent pas être retirées de force aux processus qui les utilisent (condition de non-préemption).
• Il existe une chaîne circulaire de processus où chacun détient une ressource requise par le suivant (condition d'attente circulaire).

Récupération après un blocage

Plusieurs facteurs entravent la reprise après une impasse :

• Il est difficile de savoir si le système est réellement en panne ou non.
• Il existe peu de moyens efficaces pour suspendre un processus et le reprendre plus tard.
• La suspension/reprise engendre des dépenses considérables et nécessite l'intervention d'un opérateur.
• La récupération d'une petite impasse est raisonnable, mais à grande échelle, elle exige un travail énorme.

Les processus peuvent être supprimés selon un ordre de priorité :

• Si les priorités n'existent pas, l'opérateur doit prendre une décision arbitraire.
• Les priorités peuvent être erronées ou confuses à cause de contraintes temporelles (échéances imminentes).
• Déterminer la décision optimale peut nécessiter un effort considérable.