Discussion :

[totoscill]

Bonjour,

Je voudrais partager une zone mémoire que j'ai allouer (via un malloc) en RAM entre plusieurs process.
Cette zone n'est accessibles qu'en lecture donc je me demande s'il y a la neccesité de protéger cette zone par sémaphore.

Qu'en dites vous?

Je vous remercie.

[Médinoc]

À ma connaissance, la mémoire allouée par malloc() n'est pas partageable.
Il faut utiliser les fonctions de gestion de mémoire partagée pour allouer/ouvrir un segment partagé.

Quant à ton problème, ben ça dépend: S'il y a UN process (ou plus) qui écrit, tu dois protéger (le mieux ici est un verrou lecteurs/écrivain, mais ça n'est pratiquement jamais disponible nativement).
Si ta mémoire n'est accessible qu'en lecture après partage, et que RIEN n'écrit dessus, il n'est pas nécessaire de la protéger.

[totoscill]

OK,

Je suis d'accord qu'il existe avec toi, la memoire alloué via un malloc n'est pas partageable avec tout mes process (il vaut mieux utiliser les dataseg).
Je te remercie. Je ne savais plus trop si c'était necessaire.

[Goten]

Soit dit en passant.. si tu codes en C++ oublies malloc et utilise new.

[Mac LAK]

Je suis d'accord qu'il existe avec toi, la memoire alloué via un malloc n'est pas partageable avec tout mes process (il vaut mieux utiliser les dataseg).

Non, il vaut mieux utiliser les fonctions de l'OS pour ça...

A savoir :

• Windows : CreateFileMapping, MapViewOfFile, UnmapViewOfFile, CloseHandle.
• Unix : shmget, shmctrl, shmat, shmdt

Ensuite, MSDN ou man seront tes amis.

[totoscill]

Non, il vaut mieux utiliser les fonctions de l'OS pour ça...

A savoir :

• Windows : CreateFileMapping, MapViewOfFile, UnmapViewOfFile, CloseHandle.
• Unix : shmget, shmctrl, shmat, shmdt

Ensuite, MSDN ou man seront tes amis.

Je suis d'accord aussi et une ZMP est bien créée avec ces fonctions. Mais le problème avec ces fonction est qu'il font appelle à chaque fois à un fichier "SBR" auquelle il faut accéder lors de chaque "mapping mémoire" et cela prend un peu de temps (dans mon cas puisque l'architecture de l'application que j'ai récupéré n'est pas très bien faîtes).
De plus lors de l'utilisation d'une ZMP comme tu propose, il me semble qu'il faut utiliser des mutex pour protéger la mémoire partagée (peut être pas en lecture). Ce que je veux donc c'est garder en RAM une copie de la ZMP créer pour y avoir accès quand je le veux (c'est ce qui est fait actuellement mais cette zone RAM est créée à chaques accès à une fonction d'où une perte de temps inutile).

[Mac LAK]

Je suis d'accord aussi et une ZMP est bien créée avec ces fonctions. Mais le problème avec ces fonction est qu'il font appelle à chaque fois à un fichier "SBR" auquelle il faut accéder lors de chaque "mapping mémoire" et cela prend un peu de temps (dans mon cas puisque l'architecture de l'application que j'ai récupéré n'est pas très bien faîtes).

Mouais... Bizarre, ton truc, j'ai jamais eu de fichiers "réels" sur une mémoire partagée, sauf via des librairies d'abstraction très mal foutues.

De plus lors de l'utilisation d'une ZMP comme tu propose, il me semble qu'il faut utiliser des mutex pour protéger la mémoire partagée (peut être pas en lecture). Ce que je veux donc c'est garder en RAM une copie de la ZMP créer pour y avoir accès quand je le veux (c'est ce qui est fait actuellement mais cette zone RAM est créée à chaques accès à une fonction d'où une perte de temps inutile).

???

Non, la mémoire partagée est crée par le premier processus lancé l'utilisant, et détruite lorsque l'on ferme le dernier handle dessus... Tant qu'un processus maintient un handle ouvert, elle reste active, en RAM, et accessible par tout le monde avec un overhead ridicule...
Si elle est déjà mappée dans le contexte du processus (MapViewOfFile ou shmat), l'accès est exactement aussi rapide qu'avec n'importe quelle variable allouée, locale ou globale de ton processus. Au pire, tu interdis le swap de cette zone et c'est tout...

Tu n'as besoin d'aucun mutex si tout le monde ne fait que lire dedans, et elle ne doit être verrouillée que s'il y a écriture de façon concurrente.

[totoscill]

Mouais... Bizarre, ton truc, j'ai jamais eu de fichiers "réels" sur une mémoire partagée, sauf via des librairies d'abstraction très mal foutues.

"CreateFileMapping: Creates or opens a named or unnamed file mapping object for a specified file. (MSDN)".

Donc il te faut bien un fichier pour mapper ta ZMP. Pour moi c'est un fichier SBR.
Tu est d'accord?

???

Non, la mémoire partagée est crée par le premier processus lancé l'utilisant, et détruite lorsque l'on ferme le dernier handle dessus... Tant qu'un processus maintient un handle ouvert, elle reste active, en RAM, et accessible par tout le monde avec un overhead ridicule...
Si elle est déjà mappée dans le contexte du processus (MapViewOfFile ou shmat), l'accès est exactement aussi rapide qu'avec n'importe quelle variable allouée, locale ou globale de ton processus. Au pire, tu interdis le swap de cette zone et c'est tout...

Tu n'as besoin d'aucun mutex si tout le monde ne fait que lire dedans, et elle ne doit être verrouillée que s'il y a écriture de façon concurrente.

J'aurais été l'homme le plus heureux du monde si la personne qui à créer l'architecture aurait pensé comme toi.
Mais ce n'est pas le cas. C'est pour celà que je suis obligé de "bidouiller" un peu pour gagner du temps process.

[Mac LAK]

Donc il te faut bien un fichier pour mapper ta ZMP. Pour moi c'est un fichier SBR.
Tu est d'accord?

Le nom est trompeur, parce que la fonction fait d'autres choses que ça... Et non, il n'y a AUCUN fichier "réel" créé. Cela prend à peu près le même temps qu'une allocation globale.
Le "secret" est dans le premier paramètre, INVALID_HANDLE_VALUE, qui permet justement de ne PAS s'associer avec un fichier, tout en conservant les mêmes mécanismes sous-jacents... Et donc, d'avoir de la mémoire partagée.

Ce qui te "trompe", c'est que contrairement à Posix qui possède des fonctions "dédiées" à la mémoire partagée, Windows utilise des effets de bords de fonctions existantes pour permettre la création d'une telle mémoire. Et donc, les noms des fonctions ne sont pas très ... parlants, on va dire.

J'aurais été l'homme le plus heureux du monde si la personne qui à créer l'architecture aurait pensé comme toi.
Mais ce n'est pas le cas. C'est pour celà que je suis obligé de "bidouiller" un peu pour gagner du temps process.

Sauf que le type qui a "conçu" l'archi ne peut rien faire contre les mécanismes de l'OS : la mémoire partagée n'est détruite qu'à la fermeture du dernier handle !

Donc, si tu veux empêcher qu'elle soit systématiquement détruite / reconstruite, tu n'as qu'à lancer un micro-processus qui va simplement la maintenir active en l'ouvrant, c'est aussi simple que ça...

[Médinoc]

Pardonnez mon ignorance, mais... Que signifie SBR, en fait?

[totoscill]

Le nom est trompeur, parce que la fonction fait d'autres choses que ça... Et non, il n'y a AUCUN fichier "réel" créé. Cela prend à peu près le même temps qu'une allocation globale.
Le "secret" est dans le premier paramètre, INVALID_HANDLE_VALUE, qui permet justement de ne PAS s'associer avec un fichier, tout en conservant les mêmes mécanismes sous-jacents... Et donc, d'avoir de la mémoire partagée.

Ce qui te "trompe", c'est que contrairement à Posix qui possède des fonctions "dédiées" à la mémoire partagée, Windows utilise des effets de bords de fonctions existantes pour permettre la création d'une telle mémoire. Et donc, les noms des fonctions ne sont pas très ... parlants, on va dire.

D'accord, c'est vrai que ce n'est pas très explicite. Merci

Sauf que le type qui a "conçu" l'archi ne peut rien faire contre les mécanismes de l'OS : la mémoire partagée n'est détruite qu'à la fermeture du dernier handle !

Donc, si tu veux empêcher qu'elle soit systématiquement détruite / reconstruite, tu n'as qu'à lancer un micro-processus qui va simplement la maintenir active en l'ouvrant, c'est aussi simple que ça...

C'est vrai, je vais voir ce que je peux faire. Je te remercie.

[totoscill]

Pardonnez mon ignorance, mais... Que signifie SBR, en fait?

AUcune idée. J'ai essayer de trouver la signification mais en vain.

[Mac LAK]

Pardonnez mon ignorance, mais... Que signifie SBR, en fait?

C'est "Shared Block Record", je crois.

Le noyau NT interdit strictement à deux processus de se partager de la mémoire, d'où l'absence d'API "parlante" à ce sujet. On ne peut accéder à la mémoire d'un autre processus que via OpenProcess (et il faut les droits adéquats pour ça, en plus de savoir dans quoi on tape), ou via le file mapping.

Officiellement, et pour les processus l'utilisant, cette mémoire partagée est créée sur le swap de l'OS, au travers de mécanismes d'indirection comme n'importe quelle mémoire swappable.
En pratique, cette page n'est jamais swappée vers le fichier d'échange, elle reste en RAM. Il n'y a pas de fichier visible, car le fichier de swap est considéré comme de la mémoire pour l'OS : la mémoire partagée ne fait qu'exploiter ce mécanisme d'indirection. C'est la fonction "MapViewOfFile" qui permet de la rendre visible pour le processus, et qui assure également sa conservation en RAM (vu qu'elle est officiellement utilisée, donc elle n'est plus swappable...).

C'est un peu plus clair ?


Pour les curieux / courageux : Petite explication détaillée sur MSDN.

[Médinoc]

Ça me parait bizarre qu'elle ne soit plus swappable: À mon avis, si les N processus qui l'utilisent sont tous "idle", je ne vois pas pourquoi les pages mappées ne seraient pas swappées comme toute autre page mémoire s'il faut de la place.

PS: Personnellement, je considère le fichier de swap comme un fichier visible (le pagefile.sys). Mais il reste clair que ce fichier n'est pas créé par CreateFileMapping().

[Mac LAK]

Ça me parait bizarre qu'elle ne soit plus swappable: À mon avis, si les N processus qui l'utilisent sont tous "idle", je ne vois pas pourquoi les pages mappées ne seraient pas swappées comme toute autre page mémoire s'il faut de la place.

Elle ne l'est pas pourtant : c'est exactement comme de la mémoire allouée par VirtualAlloc, puis verrouillée par VirtualLock. Sauf que là, c'est le MapViewOfFile qui va effectuer ce "lock"...
Ou, pour être plus précis : en général, on mappe l'intégralité de la mémoire partagée, et non pas seulement une partie. Les parties non-mappées, elles, peuvent bien sûr être swappée sans avertissement.

PS: Personnellement, je considère le fichier de swap comme un fichier visible (le pagefile.sys). Mais il reste clair que ce fichier n'est pas créé par CreateFileMapping().

En pratique, il n'y a même pas un seul "commit" vers le fichier de swap lorsque l'on crée de la mémoire partagée... Sauf, bien sûr, à volontairement fermer tous les mappings sans détruire pour autant la mémoire partagée, mais cela reste un cas plutôt rare d'utilisation. Et même là, c'est "limite" : encore faut-il que l'OS soit un peu à court de mémoire pour qu'il déclenche le swap !