Synchronisation et Communication Inter-Processus

Ce TP porte sur la synchronisation et la communication inter-processus. Il propose plusieurs exercices pratiques pour maîtriser l’utilisation des sémaphores, des mutex, des variables conditionnelles et des tubes (pipes) dans des contextes classiques de programmation concurrente. Le TP nécessite des connaissances en systèmes d’exploitation, en programmation multithread et en gestion des ressources partagées.

Objectifs

• Comprendre et implémenter la synchronisation des processus à l’aide de sémaphores.
• Appliquer les mécanismes de gestion des lecteurs et rédacteurs pour éviter les conflits d’accès.
• Développer une solution multithreadée pour le problème du dîner des philosophes sans utiliser de sémaphores.
• Concevoir un schéma de synchronisation pour gérer l’accès concurrent à une ressource partagée avec contraintes spécifiques.
• Analyser et corriger des erreurs dans la gestion des tubes nommés et anonymes en C.

Prérequis et configuration

• Connaissances de base en programmation concurrente et systèmes d’exploitation.
• Maîtrise des concepts de sémaphores, mutex, variables conditionnelles et communication inter-processus (IPC).
• Environnement de développement C avec support pour threads POSIX et IPC.
• Outils pour visualiser les diagrammes de Gantt et analyser les exécutions concurrentes.

Exercice 1 : Synchronisation selon un graphe de précédence (DAG)

Vous disposez d’un graphe orienté acyclique (DAG) représentant cinq processus P1, P2, P3, P4 et P5. Les flèches indiquent l’ordre d’exécution : un processus ne peut commencer que lorsque tous ses prédécesseurs ont terminé.

Votre tâche est d’implémenter cette synchronisation en utilisant un nombre minimal de sémaphores.

Procédure :

• Identifiez les dépendances entre processus à partir du DAG.
• Déclarez un sémaphore par dépendance critique, initialisé à 0.
• Chaque processus attend (P) sur les sémaphores correspondant à ses prédécesseurs.
• À la fin de son exécution, chaque processus signale (V) les sémaphores des processus qui en dépendent.

But : garantir que les processus s’exécutent dans l’ordre imposé par le graphe.

Résultat attendu : les processus s’exécutent sans violation de l’ordre, avec un minimum de sémaphores utilisés.

Exercice 2 : Problème des Lecteurs/Rédacteurs

Ce problème classique illustre la synchronisation entre lecteurs et rédacteurs accédant à une ressource partagée.

Vous disposez du code suivant pour les lecteurs (R) et rédacteurs (W) :

P(mutex);
Nread++;
if (Nread == 1) P(wrt);
V(mutex);
... SC: Reading ...
P(mutex);
Nread--;
if (Nread == 0) V(wrt);
V(mutex);

P(wrt);
... SC: Writing ...
V(wrt);

La table suivante donne les temps d’arrivée et de traitement estimé des lecteurs et rédacteurs :

Processus Reader	W1	W2	W3	R1	R2	R3
Date d’arrivée	1	2	5	0	1	4
Temps de traitement estimé	2	2	1	1	2	2

1. Rôle des sémaphores mutex et wrt

• mutex : protège l’accès à la variable Nread (nombre de lecteurs actifs) pour éviter les conditions de course. Sa valeur initiale est 1.
• wrt : contrôle l’accès exclusif à la ressource pour les rédacteurs. Sa valeur initiale est 1.

2. Compléter le diagramme de Gantt

À partir des temps d’arrivée et durées, remplissez le diagramme en indiquant :

• Les processus en attente (bloqués sur un sémaphore).
• Les processus actifs occupant la section critique (lecture ou écriture).

Cela permet de visualiser la synchronisation effective et la gestion des priorités entre lecteurs et rédacteurs.

Exercice 3 : Dîner des philosophes avec mutex et variables conditionnelles

Le problème du dîner des philosophes est un classique de la programmation concurrente. Ici, chaque philosophe i est représenté par un thread Ti.

Vous devez proposer une solution multithreadée utilisant uniquement des mutex et des variables conditionnelles, sans recourir aux sémaphores.

Procédure :

• Déclarez un mutex global pour protéger l’accès aux états des philosophes.
• Utilisez une variable conditionnelle par philosophe pour gérer l’attente.
• Implémentez les états des philosophes : penseur, affamé, mangeur.
• Un philosophe ne peut manger que si ses voisins ne mangent pas.
• Utilisez les variables conditionnelles pour bloquer/débloquer les philosophes selon les règles.

But : éviter l’interblocage et garantir que chaque philosophe puisse manger.

Résultat attendu : un programme fonctionnel sans utilisation de sémaphores, respectant les contraintes du problème.

Exercice 4 : Synchronisation d’accès au stade pour athlètes de trois clubs

Un stade peut accueillir simultanément un nombre quelconque d’athlètes, mais provenant d’au plus deux clubs différents parmi A, B et C.

Si un athlète du troisième club souhaite entrer, il doit attendre que tous les athlètes d’un des deux clubs présents aient quitté le stade.

1. Schéma de synchronisation avec sémaphores

Vous devez proposer une solution utilisant des sémaphores pour gérer l’accès des processus A, B et C (athlètes des clubs respectifs).

Procédure :

• Déclarez des sémaphores pour contrôler l’entrée et la sortie des athlètes.
• Maintenez un compteur du nombre d’athlètes présents par club.
• Autorisez l’entrée si le club est déjà présent ou si le nombre de clubs présents est inférieur à deux.
• Bloquez sinon, jusqu’à ce que la condition soit satisfaite.
• Initialisez les sémaphores selon leur rôle (ex : mutex à 1, autres à 0 ou selon besoin).

2. Risque de famine

Analysez si la solution proposée peut entraîner un risque de famine (processus bloqués indéfiniment).

Justification : la gestion des priorités et l’ordre d’accès doivent être étudiés pour éviter que certains athlètes ne soient toujours bloqués.

Exercice 5 : Communication inter-processus avec tubes (pipes)

Un programme C est donné, utilisant des tubes nommés et anonymes pour la communication entre processus.

1. Aperçu du programme

Le programme met en place une communication entre processus via des tubes. Il crée des processus enfants, établit des canaux de communication et échange des données.

2. Identification et correction des erreurs

Deux erreurs sont présentes :

• Erreur dans le traitement des tubes nommés : probablement une mauvaise ouverture, fermeture ou utilisation des descripteurs. Vérifiez que les tubes nommés sont créés avec mkfifo, ouverts en mode correct, et fermés après usage.
• Erreur dans le traitement des tubes anonymes : souvent liée à la duplication des descripteurs ou à leur fermeture incorrecte dans les processus parents/enfants. Assurez-vous que les descripteurs inutiles sont fermés dans chaque processus pour éviter les blocages.

Correction : ajustez les appels open(), close(), fork() et dup2() pour respecter la bonne gestion des tubes et éviter les fuites ou blocages.

Résultats attendus

• Exercice 1 : exécution des processus dans l’ordre imposé par le DAG sans violation.
• Exercice 2 : diagramme de Gantt montrant la synchronisation correcte entre lecteurs et rédacteurs.
• Exercice 3 : programme multithreadé sans interblocage, où chaque philosophe peut manger.
• Exercice 4 : accès au stade respectant la contrainte de deux clubs maximum, sans violation.
• Exercice 5 : programme C fonctionnel avec tubes, sans erreurs de communication.

Pièges courants

• Ne pas initialiser correctement les sémaphores (valeurs initiales incorrectes).
• Oublier de signaler (V) les sémaphores après la fin d’un processus, bloquant les suivants.
• Dans le problème Lecteurs/Rédacteurs, ne pas protéger la variable Nread avec mutex.
• Dans le dîner des philosophes, provoquer un interblocage en ne libérant pas les ressources.
• Dans l’accès au stade, ne pas gérer correctement le comptage des clubs présents, causant des violations de la règle.
• Dans la gestion des tubes, ne pas fermer les descripteurs inutiles dans les processus enfants ou parents, entraînant des blocages.