Jusqu'à présent j'avait toujours associé des segments de mémoire partagés avec l'appel système mmap. Mais cette année, j'ai eu un cours système où on m'a introduit les IPC Système V, et je me demande jusqu'a quel points ils sont utilisés.
Les IPC système V s'utilisent en créant un token avec ftok(). À partir de là il est possible de créer des files de messages (msgget) des segments de mémoire partagés (shmget) ou des sémaphores (semget). Et la commande ipcs permet de lister tous les IPC présent sur le système.
Or sur mon système, lorsque je lance ipcs, j'ai:
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00005d8b 32768 root 777 388 2
0x00000000 65537 mildred 600 393216 2 dest
0x00000000 98306 mildred 600 393216 2 dest
0x00000000 91324419 mildred 600 2160333 3 dest
0x00000000 88932356 mildred 600 393216 2 dest
0x00000000 196613 mildred 600 393216 2 dest
0x00000000 229382 mildred 600 393216 2 dest
0x00000000 262151 mildred 600 393216 2 dest
0x00000000 294920 mildred 600 393216 2 dest
0x00000000 327689 mildred 600 393216 2 dest
0x00000000 360458 mildred 600 393216 2 dest
0x00000000 393227 mildred 600 393216 2 dest
0x00000000 425996 mildred 600 393216 2 dest
0x00000000 458765 mildred 600 393216 2 dest
0x00000000 91357198 mildred 600 393216 2 dest
0x00000000 524303 mildred 600 393216 2 dest
0x00000000 720912 mildred 600 393216 2 dest
0x00000000 95911953 mildred 600 393216 2 dest
0x00000000 622610 mildred 600 393216 2 dest
0x00000000 917524 mildred 600 393216 2 dest
0x00000000 1245205 mildred 600 393216 2 dest
0x00000000 884758 mildred 600 393216 2 dest
0x00000000 88965143 mildred 600 393216 2 dest
0x00000000 94601240 mildred 600 393216 2 dest
0x00000000 94634009 mildred 600 393216 2 dest
0x00000000 88997914 mildred 600 12288 2 dest
0x00000000 1474587 mildred 600 393216 2 dest
0x00000000 94666780 mildred 600 393216 2 dest
0x00000000 94699549 mildred 600 393216 2 dest
0x00000000 92536863 mildred 600 393216 2 dest
0x00000000 92962850 mildred 600 393216 2 dest
0x00000000 92995620 mildred 600 12288 2 dest
0x00000000 93028389 mildred 600 393216 2 dest
0x00000000 93061158 mildred 600 12288 2 dest
0x00000000 93093927 mildred 600 393216 2 dest
0x00000000 93126696 mildred 600 12288 2 dest
0x00000000 93159465 mildred 600 393216 2 dest
0x00000000 93192234 mildred 600 12288 2 dest
------ Semaphore Arrays --------
key semid owner perms nsems
------ Message Queues --------
key msqid owner perms used-bytes messages
Donc en gros, je vois que le système dispose de quelques segments de mémoire partagés (peut être bien créés avec mmap, lorsque je vois que tous les tokens ou presque sont nuls) mais que les autres IPC restent inutilisées (si ce n'est lors de mes TP).
Ma question est la suivante: dans quelle mesure ces appels systèmes sont vraiment utilisés, et dans quelle mesure on préfère rester avec des IPC plus classiques comme les sockets ou les pipes ?
Merci
Mildred
# POSIX shared memory
Posté par castorpilot . Évalué à 2.
Par contre, je prefere shm_open, qui " Create/open or unlink POSIX shared memory objects", et qui a le bon gout d'etre appelé par un nom, et pas par une clef.
# IPC vs IPC
Posté par Thibault (site web personnel) . Évalué à 3.
"Beaucoup de programmeur rechignent à employer ces méthodes de dialogue (cf : en parlant des IPC system V), car elles ne sont pas fondées sur le concept des descripteurs de fichiers, contrairement aux tubes, aux tubes nommées ou même aux sockets. Il n'est pas possible d'employer des schémas homologènes pour traiter toutes les entrées-sorties d'un processus ni d'utiliser les méthodes de multiplexage et de traitements asynchrones [...]. Pourtant, il existe encore de nombreuses applications faisant usage de ces mécanismes, [...]."
Cela finit même sur le fait que ces appels sont désactivables facilement dans le noyau Linux lors de la compilation. Alors est-ce seulement dans un but pédagogique que d'apprendre les IPV System V (Apparus en 1983 :p) je ne sais pas, il y a s'en doute des cas ou leur usage est indispensable peut-être que quelqu'un d'autre nous éclairera la dessus.
[^] # Re: IPC vs IPC
Posté par Mildred (site web personnel) . Évalué à 2.
Cela ne m'étonne pas qu'elles soient plus ou moins dépréciées (si le noyeau permet leur désactivation, ça doit être ça). Car je trouve effectivement le système de clef ftok() qui ne garantit pas l'uncité de la clef un peu léger ... et en plus, j'ai remarqué que pour les files de messages, il était impossible de récupérer des messages de taille inconnue :(
Bon, en attendant, je continue mon TP :)
Mildred
[^] # Re: IPC vs IPC
Posté par Obsidian . Évalué à 4.
SHM+MSG+SEM => SysV
Sockets => BSD
La clé du mystère est donc en grande partie historique. Ce sont donc deux grandes réponses - différentes -, données par des mouvances - différentes - à un même problème.
Il faut également souligner certaines choses :
- Les sockets sont une tentative de conception d'un procédé de communication universel (à une époque où les machines personnelles étaient rarement en réseau, d'ailleurs). On retrouve des embryons d'héritage et de modèles objets en C, à une époque où ce n'était pas courant, et leur volonté de penser à tout dès le départ nous lègue malheureusement une interface lourde et remplies de choses qui ne servent à rien, mais qu'il faut quand même respecter.
- Si je ne me trompe pas, mmap() est beaucoup plus récent que shmxxx() et, de toutes façons, il sert implicitement à projeter en mémoire le contenu d'un fichier, ce en s'appuyant sur les mécanismes de la mémoire virtuelle. Le swap existe depuis belle lurette sur tous les systèmes mais cela n'a pas toujours été le cas. La manière la plus simple de réserver la mémoire nécessaire à cette projection reste l'allocation d'un segment de mémoire partagée. Il en reste que ce sont deux choses différentes.
- Le sémaphore de Dijkstra est un concept beaucoup plus abstrait que son implémentation sous Unix pourrait le laisser croire : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) . La raison pour laquelle c'est un pillier des IPC SysV est que ce concept implique la participation du système pour fonctionner correctement.
- L'intérêt principal des IPC SysV est de garantir l'atomicité des transactions : en effet, les fonctions semxxx() te permettent de travailler sur des tableaux de sémaphores, lesquels sémaphores ne seront mis à jour que s'ils peuvent l'être tous en même temps et en une seule fois. C'est ce qui rend la syntaxe d'appel si compliquée, d'ailleurs.
Maintenant, pourquoi ne voit-on pas plus d'IPC SysV ? D'abord parce que le monde BSD ne les a pas utilisés dès le départ. Ensuite, parce que la majorité des processus travaillent seuls et n'ont pas besoin de communiquer entre eux, tout simplement.
On ajoutera enfin que les cas où les sémaphores, pleinement implémentés, se justifient sont nombreux, mais qu'ils dépassent bien souvent le simple cas d'école. En TP, pour faire simple, on va souvent utiliser un sémaphore tout seul, histoire de dire que l'on a utilisé le système, en obligeant un processus à en attendre un autre. Et cette tâche peut très bien être remplie avec un tube. Elle l'est généralement car c'est plus simple à déclarer et à manipuler, ça fonctionne sur tous les Unices, y compris les plus anciens, ça reste dans l'esprit fichier, et surtout c'est anonyme et automatiquement libéré à la fermeture du tube ou à la mort du processus.
Enfin, les sémaphores servent beaucoup plus à réaliser des mutex qu'à synchroniser des processus (qu'ils ne bloquent pas pour le plaisir). Mais lorsque des ressources mutuellement exclusives sont exploitées par un unique processus, alors il est plus efficace pour lui de faire sa tambouille seul que de passer par un appel système. A dire vrai, un sémaphore utilisé par un seul processus ne servirait à rien (en mode bloquant), puisqu'il n'y aurait personne d'autre pour libérer la ressource et le réveiller.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.