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.