Quelles sont les principales différences entre un moniteur et un sémaphore ?
multithreading
semaphore
monitor
user919860
la source
la source
Réponses:
Un moniteur est un objet conçu pour être accessible à partir de plusieurs threads. Les fonctions ou méthodes membres d'un objet moniteur appliqueront l'exclusion mutuelle, de sorte qu'un seul thread peut effectuer une action sur l'objet à un moment donné. Si un thread exécute actuellement une fonction membre de l'objet, tout autre thread qui tente d'appeler une fonction membre de cet objet devra attendre la fin du premier.
Un sémaphore est un objet de niveau inférieur. Vous pourriez bien utiliser un sémaphore pour implémenter un moniteur. Un sémaphore n'est essentiellement qu'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 essaie d'acquérir le sémaphore, il doit attendre qu'un autre thread libère le sémaphore. Si plusieurs threads attendent lorsqu'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 toilette publique. Une seule personne peut participer à la fois. Ils verrouillent la porte pour empêcher quiconque d'entrer, font leurs affaires, puis la déverrouillent lorsqu'ils partent.
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. Quand quelqu'un rend son vélo, quelqu'un d'autre peut le prendre. Si vous avez un vélo, vous pouvez le donner à quelqu'un d'autre pour le retourner --- le lieu de location de vélos ne se soucie pas de qui le rend, tant qu'il récupère son vélo.
la source
L'explication suivante explique en fait en quoi 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 le comptage des sémaphores .
Une instruction d'attente peut bloquer l'exécution d'un processus, tandis qu'une instruction de signal peut entraîner le déblocage d'un autre processus. Cependant, il existe quelques différencesentre 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émaphore s'il n'y a pas de tâche à déverrouiller. En revanche, si un processus exécute une instruction de signal alors qu'il n'y a aucun autre processus à débloquer, il n'y a aucun 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 l'exécution sans délai. Au contraire, les utilisateurs réveillés par une opération de signal ne sont redémarrés que lorsque le moniteur est déverrouillé. En outre,
Lien: ici pour plus de lecture. J'espère que ça aide.
la source
Réponse d'une ligne:
Moniteur: contrôle qu'un seul thread à la fois peut s'exécuter dans 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)
la source
Le sémaphore permet à plusieurs threads (jusqu'à un nombre défini) d'accéder à un objet partagé. Les moniteurs permettent un accès mutuellement exclusif à un objet partagé.
Moniteur
Sémaphore
la source
java.util.ArrayList: est-ce un objet ou un conteneur de plusieurs objets? Eh bien, c'est les deux en même temps. Le sémaphore est-il donc approprié pour contrôler l'accès à celui-ci? Je dirais: non.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. Cela fait partie des raisons pour lesquelles les sémaphores peuvent être dispersés autour du code, et pourquoi il est facile d'oublier d'appeler wait ou de notifier , auquel cas le résultat sera, respectivement, de violer l'exclusion mutuelle ou de verrouiller la ressource de manière permanente.
En revanche, rien de tout cela ne peut arriver avec un moniteur. Un moniteur est fatigué directement des données (il encapsule les données) et, parce que les opérations du moniteur sont des actions atomiques, il est impossible d'écrire du code qui peut accéder aux données sans appeler le protocole d'entrée. Le protocole de sortie est appelé automatiquement lorsque l'opération du moniteur 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 remplie, le processus doit attendre jusqu'à ce qu'il soit informé d'un changement dans 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.
Extrait du matériel de cours "Processus d'interaction" de l'Open University M362.
la source
Sémaphore:
L'utilisation d'un compteur ou d'un indicateur pour contrôler l'accès à certaines ressources partagées dans un système simultané implique l'utilisation de Semaphore .
Exemple:
Les indicateurs ne révèlent que l'état actuel de la ressource, aucun décompte ou toute autre information sur les objets en attente ou en cours d'exécution sur la ressource.
Moniteur:
Un moniteur synchronise l'accès à un objet en communiquant avec les threads intéressés par l'objet, en leur demandant d'acquérir l'accès ou d'attendre qu'une condition devienne vraie.
Exemple:
la source