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

Si vous êtes après la minimisation des maux de tête, préférez les moniteurs ( synchronisé blocs / méthodes) sur des sémaphores où que vous soyez un véritable choix d'une primitive verrouillée. Ignorer les discussions académiques de la flexibilité des sémaphores. Vous êtes après la fiabilité, pas de configurabilité, n'est-ce pas?

Il est souvent affirmé que les moniteurs et les sémaphores sont équivalents (peuvent se simuler mutuellement), mais cette équivalence est beaucoup plus abstraite et moins utile que ce n'est Parfois attendus . Toute personne qui peut correctement simuler une avec l'autre n'a besoin de réponse à cette question plus.

Évidemment, les sémaphores sont votre seul choix pratique dans des situations où le nombre de fils à autoriser à saisir simultanément un bloc est supérieur à un. Donc, le véritable concurrent des moniteurs est sémaphores binaires , à savoir celles qui sont initialisées avec un nombre de 1 et seulement celles d'entre eux où vous attendez du même thread qui a finalement déverrouillé le sémaphore. Alors regardons plus près ces situations.

La différence fondamentale entre les moniteurs et les sémaphores binaires est Propriété de thread . Il a une grande conséquence, et c'est la capacité de réentrancement . La réentruisance signifie qu'un fil qui possède déjà une serrure peut l'acquérir à nouveau par opposition à une impasse. C'est une grosse affaire si votre classe a partagé l'état que vous souhaitez simplement protéger dans toutes les méthodes, mais vous ne pouvez pas vous permettre des hypothèses permanentes sur la manière dont ces méthodes s'appellent mutuellement; ou avec des traits de ceinture et d'accolades qui évoluent dans votre schéma de sécurité de thread en général.

Semaphores ne sont jamais réentrants et les moniteurs Java sont toujours réentrants. Si vous devez verrouiller le même objet à partir de nombreux emplacements de code, Les sémaphores sont sujets à des blocages Même dans des scénarios à un seul fileté - et cette limitation des sémaphores n'apporte que dans des scénarios relativement rares où les moniteurs ne sont pas vraiment un Option quand même.

La propriété de thread réduit également le risque d'oublier de verrouiller, d'oublier de déverrouiller, ou d'une activité de filetage des activités de masquage d'un autre fil. Il existe également une différence ergonomique significative dans la syntaxe Java associée.

Avis aussi Cette question < / a>; Bien qu'il utilise une terminologie différente, les meilleures réponses comprennent "mutex" pour signifier un "moniteur" Java.