Sémaphore vs moniteurs – quelle est la différence?

Quelles sont les principales différences entre un moniteur et un sémaphore ?

Un moniteur est un object conçu pour être accessible depuis plusieurs threads. Les fonctions membres ou les méthodes d’un object moniteur imposent une exclusion mutuelle, de sorte qu’un seul thread peut effectuer une action sur l’object à un moment donné. Si un thread exécute actuellement une fonction membre de l’object, tout autre thread essayant d’appeler une fonction membre de cet object devra attendre que le premier ait terminé.

Un sémaphore est un object de niveau inférieur. Vous pourriez bien utiliser un sémaphore pour implémenter un moniteur. Un sémaphore est essentiellement un compteur. Lorsque le compteur est positif, si un thread essaie d’acquérir le sémaphore, il est autorisé et le compteur est décrémenté. Lorsqu’un thread est terminé, il libère le sémaphore et incrémente le compteur.

Si le compteur est déjà nul lorsqu’un thread tente d’acquérir le sémaphore, il doit attendre qu’un autre thread libère le sémaphore. Si plusieurs threads attendent qu’un thread libère un sémaphore, l’un d’eux l’obtient. Le thread qui libère un sémaphore n’a pas besoin d’être le même thread qui l’a acquis.

Un moniteur est comme une canvastte publique. Une seule personne peut entrer à la fois. Ils verrouillent la porte pour empêcher quiconque d’entrer, de faire leurs affaires, puis de la déverrouiller à leur départ.

Un sémaphore est comme un lieu de location de vélos. Ils ont un certain nombre de vélos. Si vous essayez de louer un vélo et qu’ils en ont un gratuitement, vous pouvez le prendre, sinon vous devez attendre. Lorsque quelqu’un retourne son vélo, quelqu’un d’autre peut le prendre. Si vous avez un vélo, vous pouvez le donner à quelqu’un d’autre. Le centre de location de vélos ne se soucie pas de savoir qui le retourne, à condition qu’il récupère son vélo.

Les explications suivantes expliquent en réalité comment wait () et signal () du moniteur diffèrent de P et V du sémaphore.

Les opérations wait () et signal () sur les variables de condition dans un moniteur sont similaires aux opérations P et V sur les sémaphores de comptage.

Une instruction wait peut bloquer l’exécution d’un processus, tandis qu’une déclaration de signal peut entraîner le déblocage d’un autre processus. Cependant, il existe des différences entre eux. Lorsqu’un processus exécute une opération P, il ne bloque pas nécessairement ce processus car le sémaphore de comptage peut être supérieur à zéro. En revanche, lorsqu’une instruction d’attente est exécutée, elle bloque toujours le processus. Lorsqu’une tâche exécute une opération V sur un sémaphore, elle débloque une tâche en attente sur ce sémaphore ou incrémente le compteur de sémaphores si aucune tâche n’est à débloquer. D’un autre côté, si un processus exécute une instruction de signal lorsqu’il n’y a pas d’autre processus à débloquer, il n’y a pas d’effet sur la variable de condition. Une autre différence entre les sémaphores et les moniteurs est que les utilisateurs réveillés par une opération V peuvent reprendre leur exécution sans délai. En revanche, les utilisateurs réveillés par une opération de signal sont redémarrés uniquement lorsque le moniteur est déverrouillé. De plus, une solution de surveillance est plus structurée que celle des sémaphores car les données et les procédures sont encapsulées dans un seul module et que l’exclusion mutuelle est fournie automatiquement par l’implémentation.

Lien: ici pour plus de lecture. J’espère que cela aide.

Sémaphore permet à plusieurs threads (jusqu’à un nombre défini) d’accéder à un object partagé. Les moniteurs permettent un access mutuellement exclusif à un object partagé.

Moniteur

Sémaphore

Réponse à une ligne:

Monitor: contrôle que seul un thread à la fois peut exécuter sur le moniteur. (besoin d’acquérir un verrou pour exécuter le thread unique)

Sémaphore: un verrou qui protège une ressource partagée. (besoin d’acquérir le verrou pour accéder à la ressource)

Un moniteur est un ensemble de routines multiples protégées par un locking d’exclusion mutuelle, tandis qu’un sémaphore est une construction plus simple qu’un moniteur car il ne s’agit que d’un verrou protégeant une ressource partagée, et non d’un ensemble de routines comme un moniteur. L’application doit acquérir le verrou avant d’utiliser cette ressource partagée protégée par un sémaphore.

Les deux moniteurs et les sémaphores sont utilisés dans le même but: la synchronisation des threads. Mais les moniteurs sont plus simples à utiliser que les sémaphores, car ils gèrent tous les détails de l’acquisition et de la libération des verrous.

Une autre différence lors de l’utilisation de sémaphores est que chaque routine accédant à une ressource partagée doit acquérir explicitement un locking avant d’utiliser la ressource. Cela peut être facilement oublié lors du codage des routines traitant du multithreading. Les moniteurs, contrairement aux sémaphores, acquièrent automatiquement les verrous nécessaires.

Lorsqu’un sémaphore est utilisé pour protéger une région critique, il n’y a pas de relation directe entre le sémaphore et les données protégées. C’est en partie la raison pour laquelle les sémaphores peuvent être dispersés autour du code et pourquoi il est facile d’oublier d’appeler wait ou notify , auquel cas le résultat sera respectivement de violer l’exclusion mutuelle ou de verrouiller la ressource de manière permanente.

En revanche, il est possible que de mauvaises choses se produisent avec un moniteur. Un moniteur est fatigué directement sur les données (il encapsule les données) et, étant donné que les opérations du moniteur sont des actions atomiques, il est impossible d’écrire du code pouvant accéder aux données sans appeler le protocole d’entrée. Le protocole de sortie est appelé automatiquement lorsque l’opération de surveillance est terminée.

Un moniteur a un mécanisme intégré pour la synchronisation des conditions sous la forme d’une variable de condition avant de continuer. Si la condition n’est pas satisfaite, le processus doit attendre d’être informé d’une modification de la condition. Lorsqu’un processus attend la synchronisation des conditions, l’implémentation du moniteur prend en charge le problème d’exclusion mutuelle et permet à un autre processus d’accéder au moniteur.

Tiré du matériel de cours “Processus d’interaction” M362 Unité 3 de l’Open University.

Sémaphore:

L’utilisation d’un compteur ou d’un indicateur pour contrôler l’access à certaines ressources partagées dans un système simultané implique l’utilisation de sémaphore .

Exemple:

  1. Un guichet permettant à seulement 50 passagers d’acquérir les 50 places (ressources partagées) de tout théâtre / bus / train / promenade / salle de classe. Et autoriser un nouveau passager uniquement si une personne quitte son siège.
  2. Un indicateur binary indiquant le statut libre / occupé de toute salle de bain.
  3. Les feux de circulation sont de bons exemples de drapeaux. Ils contrôlent le débit en régulant le passage des véhicules sur les routes (ressource partagée)

Les indicateurs ne révèlent que l’état actuel de la ressource, aucun compte ou toute autre information sur les objects en attente ou en cours d’exécution sur la ressource.

Surveiller:

Un moniteur synchronise l’access à un object en communiquant avec les threads intéressés par l’object, leur demandant d’acquérir un access ou d’attendre qu’une condition devienne vraie.

Exemple:

  1. Un père peut agir comme moniteur pour sa fille, lui permettant de sortir avec un seul gars à la fois.
  2. Un enseignant qui utilise un bâton pour permettre à un seul enfant de parler dans la classe.
  3. Enfin, une technique, les transactions (via les threads) sur un object de compte synchronisé pour maintenir l’intégrité.