Différences entre les sémaphores System V et Posix
Quels sont les compromis entre l'utilisation D'un système V et D'un sémaphore Posix?
4 réponses
À Partir De O'Reilly:
- une différence marquée entre le sémaphore System V et POSIX les implémentations sont celles du système V vous pouvez contrôler combien le sémaphore nombre peut être augmenté ou diminué; alors qu'en POSIX, le nombre de sémaphores est augmenté et diminué de 1.
- les sémaphores POSIX n'autorisent pas la manipulation des permissions de sémaphore, alors que les sémaphores système V vous permettent pour modifier les autorisations de les sémaphores à un sous-ensemble de la original autorisation.
- L'initialisation et la création de sémaphores sont atomiques (à partir de perspective) dans les sémaphores POSIX.
- du point de vue de L'utilisation, les sémaphores système V sont maladroits, tandis que POSIX les sémaphores sont simples
- l'évolutivité des sémaphores POSIX (en utilisant des sémaphores sans nom) est beaucoup plus élevé que les sémaphores système V. Dans un scénario utilisateur / client, où chaque utilisateur crée ses propres instances d'un serveur, il serait préférable d'utiliser POSIX les sémaphores.
- sémaphores système V, lors de la création d'un objet sémaphore, crée un tableau de sémaphores alors que sémaphores POSIX créer un seul. En raison de cette fonctionnalité, création de sémaphore (mémoire empreinte-sage) est plus coûteux dans le système V sémaphores par rapport à POSIX les sémaphores.
- il a été dit que les performances du Sémaphore POSIX sont meilleures que Sémaphores basés sur le système V.
- les sémaphores POSIX fournissent un mécanisme pour les sémaphores à l'échelle du processus que à l'échelle du système des sémaphores. Donc, si un développeur oublie de fermer la sémaphore, à la sortie du processus sémaphore est nettoyé. En simple Termes, sémaphores POSIX fournissent un mécanisme pour non persistant les sémaphores.
Deux problèmes majeurs avec les sémaphores partagés/nommés POSIX utilisés dans des processus séparés (pas des threads): Les sémaphores POSIX ne fournissent aucun mécanisme pour réveiller un processus en attente lorsqu'un processus différent meurt tout en maintenant un verrou de sémaphore. Ce manque de nettoyage peut conduire à des sémaphores zombies qui provoqueront tout autre processus ou ultérieur qui tente de les utiliser pour bloquer. Il n'y a pas non plus de moyen POSIX de lister les sémaphores dans le système d'exploitation pour tenter de les identifier et de les nettoyer. La section POSIX sur SysV IPC spécifie les outils ipcs et ipcrm pour répertorier et manipuler les ressources globales SysV IPC. Aucun outil ou même mécanisme de ce type n'est spécifié pour POSIX IPC, bien que sous Linux ces ressources se trouvent souvent sous /shm. Cela signifie qu'un signal de mise à mort vers le mauvais processus au mauvais moment peut bloquer tout un système de processus en interaction jusqu'au redémarrage.
Un autre inconvénient est l'utilisation de la sémantique de fichier pour les sémaphores POSIX. L'implication est qu'il peut y avoir plus d'un partagées sémaphore avec le même nom, mais dans des états différents. Par exemple, un processus appelle sem_open, puis sem_unlink avant sem_close. Ce processus peut toujours utiliser le sémaphore comme dissocier un fichier ouvert avant de le fermer. Le processus 2 appelle sem_open sur le même sémaphore entre les appels sem_unlink et sem_close du processus 1, et (selon la documentation) obtient un tout nouveau sémaphore avec le même nom, mais dans un état différent de celui du processus 1. Deux sémaphores partagés portant le même nom indépendamment défait le but des sémaphores partagés.
La Limitation ci-dessus rend les sémaphores partagés POSIX inutilisables dans un système du monde réel sans garantie que des signaux insaisissables ne peuvent jamais être envoyés. La Limitation deux peut être atténuée par un codage soigneux, en assumant le contrôle de tout le code qui utilisera un sémaphore donné. Franchement, c'est plus qu'un peu surprenant qu'ils l'aient fait dans la norme telle qu'elle est.
Je sais que c'est vieux, mais pour le bénéfice de ceux qui lisent encore cette courtoisie de Google, la raison # 1 Que je trouve pour utiliser les sémaphores System V sur les sémaphores POSIX (niveau système) est la capacité d'acquérir la ressource sémaphore d'une manière qui est automatiquement renvoyée par le noyau, peu importe la façon dont le processus
Je suis d'accord que les opérations de sémaphore multiples (atomiques) sont rarement utilisées (bien qu'elles puissent être utiles lors de la mise en scène), et que L'interface System V est bizarre, mais il n'y a tout simplement aucun moyen d'obtenir de manière fiable la même sémantique de nettoyage avec les sémaphores POSIX.
Je me demande ce qui fait que les gens conçoivent de mauvaises API comme des sémaphores System V ! Uneless vous avez de très fortes raisons d'aller avec les sémaphores System V (tels que les opérations atomiques avec incrémentation-décrémentation multiple en une seule étape), vous devriez vous en tenir à POSIX nommé sémaphores.
L'article lié traite de ce qui ne va pas et non intuitif avec les sémaphores System v.