mémoire partagée en C sous systèmes Unix

Bonjour,

Voici mon problème (qui n'est pas vraiment un problème mais plutôt un choix de conception).

J'ai deux processus tournant sur une même machine. Ces deux processus n'ont pas de lien de parenté a priori (l'un n'est pas issue d'un fork de l'autre).
Je dois ouvrir un segment de mémoire partagée entre ces deux processus.

La technique habituelle est la suivante :

Dans le premier processus:
1) créer une clef k avec la fonction ftok() en lui donnant en paramètre un nom de fichier et un identifiant de projet.
2) à partir de la clef k, créer un segment de mémoire partagé identifié par l'entier id (shmget)
3) à partir de l'id, récupérer le pointeur sur cette mémoire (shmat)

Dans le second processus:
1) créer la clef k avec la fonction ftok en utilisant les mêmes arguments que dans le premier processus, on récupère ainsi la même clef.
2) à partir de k, récupérer l'id du segment de donnée (shmget)
3) à partir de l'id, récupérer le pointeur

Même si c'est la manière classique et habituelle de procéder, ce genre de génération de clef ne me plait pas, de plus je rencontre des problèmes de permissions d'accès au segment de mémoire lorsque je ne lances pas les processus en root.

J'ai donc fait la chose suivante :

Dans le premier processus:
1) utilise IPC_PRIVATE comme clef lors de la création du segment. Je récupère un id.
2) créer le segment de mémoire à partir de cet id, comme précédemment.
3) envoyer l'id au second processus (les deux processus sont des jobs MPI tournant sur la même machine, je peux le faire très simplement en utilisant MPI_Send et MPI_Recv).

Dans le second processus:
1) attendre (MPI_Recv) que le premier processus envoie l'id
2) récupérer (shmget) un pointeur sur le segment à partir de cet id.

Avec cette solution, pas de problème de permission, ni de génération de clefs utilisant un nom de fichier et un identifiant de projet.
Cela fonctionne.

Ma question : ... est-ce propre ? Est-ce que ça fonctionnera toujours ou est-ce que c'est un coup de bol du à certains paramètres cachés ?

Merci !

Citation:

---

Envoyé par sunmat

Même si c'est la manière classique et habituelle de procéder, ce genre de génération de clef ne me plait pas

---

Et pourquoi ?
Personnellement, si deux programmes doivent taper dans la même ipc, j'utilise l'astuce suivante: ftok(".", getuid())
Après-tout, "." est aussi un fichier !!! Ainsi, comme généralement l'utilisateur appelle les deux programmes à partir du même répertoire de départ et que les deux programmes sont lancés par le même uid, la clef générée sera forcément commune aux deux ; mais différente d'un autre utilisateur qui appèlerait lui-aussi les deux programmes
Juste un détail: si le uid est root, ftok() n'apprécie pas du tout son second paramètre à 0. Donc ma vraie syntaxe est

Code:

---

ftok(".", (getuid() & 0xff) != 0 ?getuid() :-1)

---

Citation:

---

Envoyé par sunmat

, de plus je rencontre des problèmes de permissions d'accès au segment de mémoire lorsque je ne lances pas les processus en root.

---

Là ça devient bizarre. Faudrait vérifier tes paramètres shmget() et surtout la présence des flags SHM_R et/ou SHM_W

Citation:

---

Envoyé par sunmat

J'ai donc fait la chose suivante :

Dans le premier processus:
1) utilise IPC_PRIVATE comme clef lors de la création du segment. Je récupère un id.
2) créer le segment de mémoire à partir de cet id, comme précédemment.
3) envoyer l'id au second processus (les deux processus sont des jobs MPI tournant sur la même machine, je peux le faire très simplement en utilisant MPI_Send et MPI_Recv).

Dans le second processus:
1) attendre (MPI_Recv) que le premier processus envoie l'id
2) récupérer (shmget) un pointeur sur le segment à partir de cet id.

Avec cette solution, pas de problème de permission, ni de génération de clefs utilisant un nom de fichier et un identifiant de projet.
Cela fonctionne.

Ma question : ... est-ce propre ? Est-ce que ça fonctionnera toujours ou est-ce que c'est un coup de bol du à certains paramètres cachés ?

Merci !

---

J'avais déjà fait ça aussi. Aller taper dans des IPC en utilisant leur id. Effectivement ça marche. Mais bon, si la norme précise de passer par shmget() en y donnant une clef de base, c'est qu'il y a une raison. Malheureusement je ne peux pas répondre plus précisément à tes questions.

Cependant, à mon avis, tu devrais quand-même te concentrer sur ftok(). Cette fonction est pas mal foutue et si elle a été créée, ce n'est pas sans une bonne raison...

Merci !

Le problème de générer des clefs avec ftok() est que je dois utiliser des fichiers ou des identifiants de projets à chaque fois que je veux en créer une nouvelle. Or mon application est fortement multi-processus, et chaque processus va éventuellement ouvrir plusieurs segments avec d'autres processus. Je dois m'assurer de créer de nouvelles clefs à chaque fois, donc je ne peux pas me permettre d'utiliser toujours "." comme nom de fichier. Si je joue sur l'identifiant de projet, je n'ai que 256 clefs possibles, c'est pas énorme...

Pour les permissions, je n'ai pas les flags SHM_R et SHM_W, j'ai utilisé IPC_CREAT et IPC_EXCL. L'erreur vient peut-être de là...

Bon, pour le moment ma seconde solution fonctionne. S'il s'avère qu'il y a des problèmes dépendants de la plateforme, ce ne sera que quelques lignes à changer...

Citation:

---

Envoyé par sunmat

Merci !

Le problème de générer des clefs avec ftok() est que je dois utiliser des fichiers ou des identifiants de projets à chaque fois que je veux en créer une nouvelle. Or mon application est fortement multi-processus, et chaque processus va éventuellement ouvrir plusieurs segments avec d'autres processus. Je dois m'assurer de créer de nouvelles clefs à chaque fois, donc je ne peux pas me permettre d'utiliser toujours "." comme nom de fichier. Si je joue sur l'identifiant de projet, je n'ai que 256 clefs possibles, c'est pas énorme...

---

Pourquoi "plusieurs segments" ? Qu'est-ce qui t'empêche de n'en ouvrir qu'un seul bien gros et le mapper comme il faut pour que tes processus ne tapent que dans la partie qui leur est allouée ???

Citation:

---

Envoyé par sunmat

Pour les permissions, je n'ai pas les flags SHM_R et SHM_W, j'ai utilisé IPC_CREAT et IPC_EXCL. L'erreur vient peut-être de là...

---

Les flags SHM_R et SHM_W sont issus d'Unix. Il est possible qu'ils n'existent plus sous Linux. Mais si tu fais un man de shmget(), tu verras que le second paramètre "shmflg" est un entier composé d'un mixage entre:
- IPC_CREAT et IPC_EXCL (commun à toutes les fonctions xxxget())
- mode d'accès => valeur numérique octale identique à celle du chmod (sauf que le droit "x" n'est pas pris en compte). Tu peux la mettre en octal comme 0666 ou bien lui mettre des constantes standard comme S_IRUSR | S_IWUSR | S_IRGRP | ...

Donc si tu fais un truc ressemblant à

Code:

---

shm=shmget(key, IPC_CREAT|IPC_EXCL|0660)

---

tu ne devrais plus avoir de problème de droits d'accès...

Tu peux télécharger mon cours sur les IPC ici http://fr.lang.free.fr/cours/IPC_Csyst_v1.0.pdf

J'avais utilisé 0666 et non 0660, donc ça aurais du fonctionner aussi...

Citation:

---

Pourquoi "plusieurs segments" ? Qu'est-ce qui t'empêche de n'en ouvrir qu'un seul bien gros et le mapper comme il faut pour que tes processus ne tapent que dans la partie qui leur est allouée ???

---

C'est une idée, en effet, à "petites" échelles, car le second argument de shmget est un entier 32bits pour la taille, or mon code devrait tourner avec une RAM de 128Go, sur laquelle je devrais ouvrir plusieurs Go de mémoire partagée. Pris individuellement, la taille des segments peut être décrite sur un entier 32bits. Mis bouts à bout, c'est impossible. :(

Citation:

---

Les flags SHM_R et SHM_W sont issus d'Unix. Il est possible qu'ils n'existent plus sous Linux.

---

Mon code n'est même pas censé tourner sur un Linux simple, mais sur un supercalculateur d'IBM :?, je ne sais même pas quel système d'exploitation sera lancé dessus, donc je dois faire le plus général possible (au vu des autres bibliothèques utilisées ça doit quand même être issue d'Unix).

En tout cas merci pour ton aide !

EDIT: à non en fait shmget prend un argument de type size_t, donc je peux supposer que sur les systèmes d'exploitation orientés HPC ils auront mis size_t = uint64_t ou équivalent. Mais ça ne règle pas un autre problème : pour les sémaphores aussi il faut générer une clef, or je ne sais pas à l'avance combien de processus seront lancés ni combien de segments ils voudront ouvrir. Je ne sais donc pas a priori combien de sémaphores créer, je dois les créer à la demande des processus, ce qui ne fait que déplacer le problème de la mémoire partagée aux sémaphores.

Citation:

---

Envoyé par sunmat

J'avais utilisé 0666 et non 0660, donc ça aurais du fonctionner aussi...

---

Exact. Donc c'est un problème à creuser réellement et non prendre la solution de facilité de faire tourner le processus en tant que root.
Peut-être que tu pourrais faire partager ton code sauf si c'est confidentiel.

Citation:

---

Envoyé par sunmat

C'est une idée, en effet, à "petites" échelles, car le second argument de shmget est un entier 32bits pour la taille, or mon code devrait tourner avec une RAM de 128Go, sur laquelle je devrais ouvrir plusieurs Go de mémoire partagée. Pris individuellement, la taille des segments peut être décrite sur un entier 32bits. Mis bouts à bout, c'est impossible. :(

---

Arf. Peut-etre que tu devrais nous donner les conditions initiales de ton truc afin qu'on ait le plus de billes pour te conseiller au mieux. En l'état, j'imagine mal un projet devant utiliser plusieurs Go de mémoire parce qu'il y a de grandes chances que tu fasses exploser ta RAM. Parce que, que ce soit en une fois ou en plein de petits bouts, la RAM utilisée, elle, reste la même => c'est la somme cumulée de touts les petits bouts !!!
Donc si ton projet nécessite une grande quantité de datas à gérer, vaudrait mieux t'orienter vers des outils appropriés pour ça => les fichiers ou mieux, les bdd

Citation:

---

Envoyé par sunmat

EDIT: à non en fait shmget prend un argument de type size_t, donc je peux supposer que sur les systèmes d'exploitation orientés HPC ils auront mis size_t = uint64_t ou équivalent. Mais ça ne règle pas un autre problème : pour les sémaphores aussi il faut générer une clef, or je ne sais pas à l'avance combien de processus seront lancés ni combien de segments ils voudront ouvrir. Je ne sais donc pas a priori combien de sémaphores créer, je dois les créer à la demande des processus, ce qui ne fait que déplacer le problème de la mémoire partagée aux sémaphores.

---

Attention, un sémaphore n'est jamais associé à un processus mais à une ressource. Il protège la ressource unique face à un accès concurrent de 2, 3 ou 300 processus.
Donc en fait, t'auras autant de sémaphores que de zones de ta mémoire attaquées.

Citation:

---

Envoyé par sunmat

Mon code n'est même pas censé tourner sur un Linux simple, mais sur un supercalculateur d'IBM :?, je ne sais même pas quel système d'exploitation sera lancé dessus, donc je dois faire le plus général possible (au vu des autres bibliothèques utilisées ça doit quand même être issue d'Unix).

---

Heureusement que c'est de la famille Unix parce que les IPC ne sont pas connues du coté obscur de la force...

Citation:

---

Envoyé par sunmat

En tout cas merci pour ton aide !

---

Pas de pb.

Bonjour,

Est-ce une obligation d'utiliser les segments de mémoire partagée, ou bien peux-tu utiliser autre chose ?

En effet, dans ton cas, je ne suis pas certain que ce soit judicieux de passer par ces mécanismes, mais ca va beaucoup dépendre de ce que tu peux ou non faire, et de ce a quoi tu as le droit, et également de ce que tu dois faire.

Idée de piste : depuis MPI 2, il est possible d'accéder en lecture et en écriture a la mémoire du voisin, exactement comme des SHM, mais avec des problématiques d'accès massivement concurrents probablement plus simple a gérer.

Citation:

---

Envoyé par gangsoleil

Idée de piste : depuis MPI 2, il est possible d'accéder en lecture et en écriture a la mémoire du voisin, exactement comme des SHM, mais avec des problématiques d'accès massivement concurrents probablement plus simple a gérer.

---

Je ne savais pas cela, c'est une piste à creuser.

EDIT: je pense avoir trouvé le problème : en utilisant 0666 je donne "trop" de permissions pour un utilisateur simple, donc il me refusait la création du segment de mémoire partagée et des sémaphores. En utilisant 0600 ça semble fonctionner (à confirmer...).

J'ai pris la solution de ne créer qu'un seul segment de mémoire partagée et un jeu de sémaphores unique : j'ai pu borner la taille du segment et le nombre de sémaphore nécessaire, et mapper correctement. Je pense que je peux mettre ce sujet en "résolu".

Citation:

---

Envoyé par sunmat

je pense avoir trouvé le problème : en utilisant 0666 je donne "trop" de permissions pour un utilisateur simple, donc il me refusait la création du segment de mémoire partagée et des sémaphores. En utilisant 0600 ça semble fonctionner (à confirmer...).

---

C'est effectivement une hypothèse possible.
De mon coté j'avais aussi réfléchi au truc et j'étais venu proposer la mienne: il se pourrait que la première fois que t'as créé ton shm, t'aies pas mis de droit (oubli). Et donc le système a mis des droits au hasard (en fonction de la valeur qu'il avait en mémoire à ce moment là). Et ensuite les fois suivante, même si t'as réparé ton oubli ça ne marche plus car l'appel shm ne fait qu'ouvrir la zone et non la créer et donc les droits positionnés ne changent plus. C'était un truc plausible que t'aurais pu vérifier.
Si c'est ça, alors faut détruire ton ipc => ipcrm puis relancer ton programme. La shm sera recréée avec les bons droits...

Citation:

---

Envoyé par sunmat

J'ai pris la solution de ne créer qu'un seul segment de mémoire partagée et un jeu de sémaphores unique : j'ai pu borner la taille du segment et le nombre de sémaphore nécessaire, et mapper correctement.

---

Ca c'est bien !!!

Citation:

---

Envoyé par Sve@r

Si c'est ça, alors faut détruire ton ipc => ipcrm puis relancer ton programme.

---

Oui en ce moment je passe mon temps à détruire des sémaphores et des segments partagés en débuggant mon programme XD