Est-il préférable de se synchroniser avec les sémaphores ou avec les moniteurs?

Est-il mieux de se synchroniser avec les sémaphores ou avec les moniteurs?

  • quel est votre problème spécifique qui requiert une synchronisation?
  • En général
  • généralement un ou l'autre est meilleur que l'autre, dans le même temps également pour le pire.
InformationsquelleAutor farm ostrich | 2011-02-22
  1. 14

    "Mieux" dépend du contexte. Ils sont "tout aussi puissant", selon James McParlane. Je recommande fortement la visualisation son blog, pour une discussion sur les différences.

    Voici un petit guide que j'ai trouvé:

    Sémaphores

    • Peut être utilisé n'importe où dans un programme, mais ne doit pas être utilisé dans un moniteur
    • Wait() n'est pas toujours bloquer l'appelant (c'est à dire, lorsque le sémaphore compteur est supérieur à zéro).
    • Signal() soit sorti un thread bloqué, si il y en a un, ou augmente le sémaphore compteur.
    • Si Signal() sorti un thread bloqué, l'appelant et l'a publié thread à la fois continuer.

    Les Variables De Condition

    • Ne peut être utilisé dans les écrans
    • Wait() toujours bloque l'appelant.
    • Signal() soit sorti un thread bloqué, si il y en a un, ou si le signal est perdu, comme si cela n'arrive jamais.
    • Si Signal() sorti un thread bloqué, l'appelant rendements du moniteur (Hoare type) ou continue (Mesa de Type). Seulement l'un de l'appelant ou de l'sorti thread peut continuer, mais pas les deux.

    Cette information à partir de: http://www.cs.mtu.edu/~shene/NSF-3/e-Book/MONITOR/sema-vs-monitor.html

    Quelques ressources utiles:

    • Ce qui est intéressant en général, mais n'est pas directement applicable à Java, et donc quelque peu à confusion. Hoare et Mesa moniteurs wha?
    • Oui, la question a été posée pour Java, mais la réponse n'est pas lié à Java.
    InformationsquelleAutor JYelton
  2. 8

    Si vous êtes après des maux de tête à la minimisation de l', préfèrent les moniteurs (synchronized blocs/méthodes) sur les sémaphores, où que vous vous sentez un réel choix d'une installation de fermeture primitive.
    Ignorer académique de parler de la flexibilité des sémaphores. Vous êtes à la fiabilité, pas de possibilités de configuration, n'est-ce pas?

    Il est souvent affirmé que les moniteurs et les sémaphores sont équivalentes (peut simuler les uns des autres), mais cette équivalence est beaucoup plus abstrait et moins utile que est parfois attendus.
    N'importe qui peut correctement simuler un avec l'autre n'a pas besoin de répondre à cette question plus.

    Évidemment, les sémaphores sont votre seul choix pratique dans les situations où le nombre de threads à être autorisés à entrer simultanément un bloc est plus grand que un. Donc le vrai concurrent de moniteurs sont sémaphores binaires, à savoir ceux qui sont initialisés avec un nombre de 1, et en outre, ceux d'entre eux où vous pouvez vous attendre le même thread que celui qui a fait le verrouillage éventuellement débloquer le sémaphore. Donc, nous allons regarder de plus près à ces situations.

    La différence fondamentale entre les moniteurs et les sémaphores binaires est fil propriété. Il a une grande conséquence, et qui est la capacité de réentrance. La réentrance signifie qu'un thread qui possède déjà un verrou peut l'acquérir à nouveau, par opposition à l'interblocage. C'est une grosse affaire si votre classe a l'état partagé que vous voulez tout simplement à protéger dans toutes les méthodes, mais ne peut pas se permettre permanent des hypothèses sur la façon dont ces méthodes s'appellent les uns les autres; ou avec une ceinture et bretelles traits qui évoluent dans votre fil plan de sécurité en général.

    Les sémaphores sont jamais réentrant et Java les moniteurs sont toujours réentrant. Si vous avez besoin de verrouiller le même objet de beaucoup de code endroits, les sémaphores sont sujettes à des blocages même en mono-thread scénarios - et cette limitation de sémaphores apporte tous les avantages que dans relativement rares scénarios où les moniteurs ne sont pas vraiment une option, de toute façon.

    Fil propriété également drammatically réduit le risque d'oublier de verrouiller, de l'oubli pour déverrouiller, ou un thread activités de masquage des activités d'un autre thread. Il est également très ergonomique différence dans la syntaxe Java.

    Avis aussi cette question; bien qu'il utilise une terminologie différente, la meilleure des réponses il n'y comprendre "mutex" pour dire " Java "moniteur".

    InformationsquelleAutor Jirka Hanika
  3. 3

    À confirmer, par moniteurs nous entendons le bon vieux synchronized mot-clé.

    Première question, avez-vous besoin de votre serrure pour avoir un compteur?

    1. Un Sémaphore peut avoir un contre plus d'un. Si vous avez besoin de protéger la N des ressources, le Sémaphore est le meilleur. Décision facile à prendre.
    2. Si vous êtes à la protection d'une ressource unique, c'est le cas intéressant où un Sémaphore(1) et le moniteur sont également applicables.

    La J2SE 5.0, la simultanéité de l'article donne de très bons conseils ici. Les moniteurs sont limitées en raison de :

    • Aucun moyen de faire marche arrière d'une tentative d'acquérir un verrou qui est déjà jugé, ou d'abandonner après avoir attendu pendant une période de temps spécifiée, ou pour annuler une tentative de verrouillage après une interruption.
    • Aucun moyen de modifier la sémantique de la serrure, par exemple, à l'égard de la réentrée, lecture et écriture de protection, ou de l'équité.
    • La synchronisation est réalisée dans des méthodes et des blocs, et donc de limiter l'utilisation de la stricte structurées par bloc de verrouillage. En d'autres termes, vous ne pouvez pas acquérir un verrou sur une méthode et le relâcher dans un autre.

    Si l'un de ces éléments est important pour vous - sauvegarde hors tension après un délai d'attente est un excellent exemple - puis aller avec un Sémaphore. Si non, un moniteur est bien.

    InformationsquelleAutor Air
  4. 2

    Tout d'abord, vous devez décider quel JDK êtes-vous à l'aide.
    Les premières versions de Java, où seule condition de Fils. Depuis le Tigre de Java (5.0), de nouvelles classes ont été introduites pour gérer la concurrence d'accès.
    En particulier, un ensemble complet a été fourni, l' java.util.simultanées.

    Dans mon expérience, j'ai constaté que les moniteurs sont mieux, car ils ont laissé le code plus propre. En outre, à l'aide de leur laisser le code plus facile à comprendre. Ils sont généralement mis en œuvre par le biais d'une classe qui implémente l' de Verrouillage interface: le plus célèbre des implémentations fournies par le JDK sont les ReentrantLock classe, qui définit un général de verrouillage, et le ReentrantReadWriteLock classe, qui offre un écrire et/ou lire de verrouillage.

    Approuve, un verrou est utilisé pour activer/désactiver l'accès à un objet partagé (par exemple, une liste d'objets).

    Un Sémaphore objet est synchronisé utilisé pour coordonner et de contrôler les threads (il y a beaucoup de synchroniseurs fourni dans le dernier Jdk, comme Sémaphore, CyclicBarrier, CountdownLatch, et Échangeur de classes).
    Par exemple, avec un Sémaphore vous pouvez libérer un nombre fixe de jetons à votre pool de Threads et donc de décider du montant des opérations qui peuvent être exécutées simultanément. Personnellement, je n'aime pas cette approche, car l'utilisation d'un pool de thread avec des contrats à Terme et les Écluses d'aboutir au même résultat par une utilisation plus propre et plus sûre.

    Plus d'informations peuvent être trouvées dans ce livre: "Java de la Simultanéité dans la Pratique" et dans ce IBM tutoriel: "La simultanéité dans le JDK 5.0". De beaux exemples peuvent être trouvés ici.

    InformationsquelleAutor JeanValjean