|
Les sémaphores et les moniteurs sont des primitives de synchronisation utilisées dans la programmation simultanée pour gérer l'accès aux ressources partagées et éviter les conditions de concurrence. Cependant, ils diffèrent par leur structure, leur application et la manière dont ils sont utilisés. Voici un aperçu des principales différences :
1. Structure et mise en œuvre :
* Sémaphores :
* Variables entières simples : À la base, les sémaphores sont des variables entières accessibles et modifiées à l’aide d’opérations atomiques.
* Deux opérations atomiques : Ils ont généralement deux opérations principales :
* `wait()` (ou `P()` ou `acquire()`) :Décrémente la valeur du sémaphore. Si la valeur devient négative, le processus/thread se bloque jusqu'à ce que la valeur du sémaphore soit supérieure ou égale à zéro.
* `signal()` (ou `V()` ou `release()`) :incrémente la valeur du sémaphore. S'il y a des processus/threads bloqués en attente sur le sémaphore, l'un d'eux est débloqué.
* Aucune association de données implicite : Les sémaphores ne lient pas intrinsèquement le mécanisme de synchronisation à des données spécifiques. Vous pouvez utiliser un sémaphore pour contrôler l'accès à n'importe quelle ressource partagée, mais vous devez gérer l'association manuellement.
* Moniteurs :
* Approche structurée : Les moniteurs sont des constructions de programmation plus structurées. Ils encapsulent :
* Données partagées : Variables représentant la ressource partagée protégée.
* Procédures/Méthodes : Les opérations qui accèdent et modifient les données partagées. Ce sont les seules routines autorisées à accéder directement aux données partagées.
* Variables de condition : (Important !) Variables spéciales utilisées pour la signalisation et l'attente dans le moniteur.
* Exclusion mutuelle explicite : Les moniteurs fournissent une exclusion mutuelle implicite. Un seul thread/processus peut être actif *à l'intérieur* du moniteur à un moment donné. Cette exclusion mutuelle est automatiquement appliquée par le moniteur lui-même.
2. Application de l'exclusion mutuelle :
* Sémaphores :
* Application manuelle : Les sémaphores s'appuient sur les programmeurs pour utiliser correctement les opérations `wait()` et `signal()` autour des sections critiques. C'est au programmeur de s'assurer que l'exclusion mutuelle est correctement maintenue. Des erreurs peuvent être facilement introduites. Par exemple, oublier un « signal() » peut conduire à une impasse. Placer `wait()` ou `signal()` en dehors de la section critique prévue peut entraîner des problèmes de concurrence.
* Sujet aux erreurs : Cette application manuelle est sujette aux erreurs. Il est facile de commettre des erreurs qui mettent fin à l’exclusion mutuelle ou provoquent des impasses.
* Moniteurs :
* Application implicite : Les surveillants appliquent l’exclusion mutuelle *implicitement*. Le langage/système garantit qu’un seul thread peut être actif à la fois dans le moniteur. Cela rend le raisonnement plus facile et moins sujet aux erreurs. Le compilateur ou le système d'exécution gère le verrouillage et le déverrouillage.
3. Synchronisation des conditions (attente et signalisation) :
* Sémaphores :
* À usage général, mais moins structuré pour les conditions en attente : Les sémaphores *peuvent* être utilisés pour la synchronisation des conditions (par exemple, attendre qu'une ressource soit disponible). Cependant, c'est un peu encombrant. Vous avez généralement besoin de sémaphores séparés pour l'exclusion mutuelle et pour les conditions de signalisation, ce qui rend le code plus complexe et sujet aux erreurs. Vous pouvez utiliser des sémaphores de comptage pour indiquer le nombre de ressources disponibles.
* Moniteurs :
* Variables de condition : Les moniteurs utilisent des *variables de condition* spécifiquement pour la synchronisation des conditions. Ceux-ci fournissent des opérations telles que :
* `wait(condition)` :le thread appelant libère le verrou du moniteur et attend la `condition` spécifiée. Le thread est placé dans une file d'attente associée à cette variable de condition. Le verrouillage du moniteur est libéré afin que d'autres threads puissent accéder au moniteur.
* `signal(condition)` :un thread en attente de la `condition` spécifiée est réveillé. Le thread signalé réacquiert le verrou du moniteur.
* `broadcast(condition)` (ou `signalAll(condition)`) :réveille tous les threads en attente de la `condition` spécifiée.
* Structure améliorée : Les variables de condition sont étroitement liées au moniteur et à ses données partagées, ce qui facilite la compréhension et le raisonnement sur la synchronisation des conditions au sein du moniteur.
4. Propriété et responsabilité :
* Sémaphores :
* Pas de propriété claire : N'importe quel thread peut `wait()` ou `signal()` sur un sémaphore. Il n’existe aucune notion de « possession » d’un sémaphore.
* Moniteurs :
* Effacer la propriété : Les threads doivent entrer dans le moniteur (acquérir implicitement le verrou du moniteur) avant d'accéder aux données partagées ou aux variables de condition de signalisation. Cela impose un modèle de propriété clair.
5. Réentrée :
* Sémaphores :
* Aucun concept inhérent de réentrée : Les sémaphores ne savent pas si le thread appelant « wait() » ou « signal() » contient déjà le sémaphore. L'utilisation d'un sémaphore de manière réentrante (par exemple, le même thread acquiert le sémaphore plusieurs fois sans le libérer) peut facilement conduire à une impasse.
* Moniteurs :
* Généralement non réentrant : Les moniteurs sont généralement conçus pour être *non réentrants*. Un thread qui détient déjà le verrou du moniteur ne peut pas accéder à nouveau au moniteur. Cela simplifie le raisonnement sur l'état du programme mais peut parfois nécessiter une restructuration du code. Certaines implémentations de moniteurs prennent en charge la réentrée, mais c'est moins courant.
En résumé :
| Fonctionnalité | Sémaphores | Moniteurs |
|-------------------|----------------------------------------------|----------------------------------------------------------------------------------|
| Structure | Variables entières simples | Construction structurée avec des données, des procédures et des variables de condition |
| Exclusion mutuelle | Manuel (responsabilité du programmeur) | Implicite (appliqué par le moniteur lui-même) |
| Synchronisation des conditions | Peut être utilisé, mais moins structuré | Explicite avec variables de condition (attente, signal, diffusion) |
| Sujet aux erreurs | Plus sujet aux erreurs en raison de la gestion manuelle | Moins sujet aux erreurs grâce à l'application implicite |
| Propriété | Pas de propriété claire | Effacer la propriété (le thread doit entrer dans le moniteur) |
| Réentrée | Généralement non pris en compte | Généralement non réentrant |
Quand utiliser lequel :
* Sémaphores : Bien qu’ils restent précieux, les sémaphores sont souvent considérés comme des primitives de niveau inférieur. Ils sont utiles lorsqu'un simple mécanisme de comptage est nécessaire ou lorsque les exigences de synchronisation sont très basiques. Ils sont également utiles dans les systèmes où les moniteurs ne sont pas pris en charge de manière native.
* Moniteurs : Les moniteurs sont préférés lorsqu’il s’agit de scénarios de synchronisation plus complexes. Leur approche structurée, leur exclusion mutuelle implicite et leurs variables de condition facilitent l'écriture de code concurrent correct et maintenable. Les moniteurs sont bien adaptés à la protection des structures de données partagées et à la mise en œuvre de modèles de synchronisation. De nombreux langages de programmation modernes fournissent une prise en charge intégrée des moniteurs ou des constructions similaires (par exemple, le mot-clé `synchronized` et `wait()` de Java, `notify()`, `notifyAll()` ou les méthodes `threading.Lock` et `threading.Condition` de Python).
Exemple (conceptuel - langage non spécifique) :
Exemple de sémaphore (conceptuel) :
```
mutex du sémaphore =1 ; // Sémaphore binaire pour l'exclusion mutuelle
sémaphore ressourceAvailable =0 ; // Comptage du sémaphore pour les ressources disponibles
// Sujet 1 (Producteur)
attendre(mutex);
// Accéder et modifier la ressource partagée
// Ajouter une ressource
signal(mutex);
signal (ressource disponible); // Signale qu'une ressource est désormais disponible
// Sujet 2 (Consommateur)
attendre (ressource disponible); // Attend qu'une ressource soit disponible
attendre(mutex);
// Accéder et modifier la ressource partagée
// Consommer la ressource
signal(mutex);
```
Exemple de moniteur (conceptuel) :
```
surveiller MonMonitor {
données partagées :... ;
ressource de conditionDisponible ;
méthode accessResource() {
// Acquérir implicitement le verrouillage du moniteur
while (la ressource n'est pas disponible) {
attendre (ressource disponible); // Libérer le verrouillage du moniteur, attendre sous condition
}
// Accéder et modifier les données partagées
//...
signal (ressource disponible); // Fil d'attente de signal
// Libère implicitement le verrouillage du moniteur lorsque la méthode revient
}
méthode addResource() {
//Acquérir implicitement le verrouillage du moniteur
//Ajouter une ressource aux données partagées
signal (ressource disponible); // Fil d'attente de signal
// Libère implicitement le verrouillage du moniteur
}
}
```
Dans l'exemple du moniteur, l'exclusion mutuelle est gérée automatiquement par le moniteur, ce qui le rend moins sujet aux erreurs. Les variables de condition offrent un moyen plus structuré de gérer l'attente et la signalisation par rapport à l'utilisation de sémaphores directement à cette fin.
|
