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.
[^] # Re: IPC vs IPC
Posté par Obsidian . En réponse au message IPC: mmap() vs shmget(). É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.