Pourquoi utiliseriez-vous un moniteur au lieu d'un sémaphore?

J'assiste actuellement au cours de programmation simultanée dans mon université et nous avons récemment commencé à parler du concept d'un moniteur. Bien que je comprenne la nécessité de l'exclusion mutuelle, je ne comprends pas pourquoi j'utiliserais un moniteur pour cela.

Si je comprends bien, un moniteur garantit que exactement un ou aucun processus est dans la section critique à tout moment. Nous pouvons réaliser exactement cela avec un sémaphore. De plus, nous implémentons des moniteurs (ou au moins une possibilité de les implémenter) avec des sémaphores.

Alors pourquoi devrais-je implémenter quelque chose qui fait exactement la même chose qu'un sémaphore avec un sémaphore? Quels avantages puis-je obtenir?

Ils sont presque interchangeables et l'un peut être construit à partir de l'autre. Il est quelque peu dépendant du langage qui est implémenté / préféré (par exemple Java a des moniteurs intégrés utilisant le mot-clé "synchronize"). Cependant, le sémaphore est considéré comme une entité de "niveau inférieur" que le moniteur pour les raisons et différences suivantes:

Les 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 application utilisant des sémaphores doit libérer tous les verrous qu'un thread a acquis à la fin de l'application - cela doit être fait par l'application elle-même. Si l'application ne le fait pas, aucun autre thread qui a besoin de la ressource partagée ne pourra continuer.

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 verrou 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. [1]

Voir aussi la réponse très appréciée de Stack Overflow Semaphore vs. Monitors - quelle est la différence? avec une grande / mémorable analogie avec les toilettes publiques et les supports à vélos.

Nous avons finalement discuté de la raison pour laquelle vous utiliseriez un moniteur au lieu d'un sémaphore dans la conférence d'aujourd'hui.

Cela se résume essentiellement à ceci: le moniteur et le sémaphore sont également expressifs, ce qui signifie que vous pouvez trouver une solution à un problème avec un moniteur où à l'origine un sémaphore était utilisé et vice versa.

Eh bien, nous le savions déjà, alors pourquoi utiliseriez-vous un moniteur au lieu d'un sémaphore?

Préférence personnelle. Normalement, une application de bureau utiliserait des moniteurs, laissant moins de possibilités d'erreurs, mais, en contrepartie, ayant une structure relativement gonflée. Les sémaphores, d'autre part, sont souvent utilisés dans les systèmes d'exploitation, car ils sont une structure légère, mais laissant plus de possibilités d'erreurs.

Je suppose que nous pouvons conclure que c'est une décision situationnelle, que vous ayez besoin ou non d'utiliser un moniteur ou un sémaphore. Si vous construisez un système en temps réel, vous voudrez peut-être utiliser un sémaphore, si vous construisez un programme de bureau, vous pouvez également utiliser un moniteur.

Jetez un œil à par exemple "Le petit livre des sempaphores"par Allen B. Downey. il indique et résout de nombreux problèmes de synchronisation. Vérifiez particulièrement les solutions bâclées, et vous verrez que les sémaphores sont un mécanisme de très bas niveau, très puissant mais extrêmement facile à utiliser, où les erreurs simples ont de terribles conséquences (aggravées par le fonctionnement non déterministe inhérent des programmes concurrents). Il est par exemple facile d'oublier de forcer l'exclusion mutuelle, d'opérer sur le mauvais sémaphore, etc. Les moniteurs offrent des solutions préemballées pour les cas les plus souvent utilisés, et emportent avec eux la plupart des avantages de la programmation orientée objet (c.-à-d., Vous savez que la seule façon de jouer avec les variables gérées par le moniteur est à travers ses opérations). L'inconvénient est qu'ils ne peuvent pas être installés facilement dans des langages non orientés objet,