IPC memoire partagee

IPC memoire partagee - C - Programmation

Marsh Posté le 08-03-2005 à 14:41:12    

Bonjour  
 
J'ai un terrible probleme d'IPC et de memoire partagee.
 
Je cree un pere qui execute le code suivant :
 

Code :
  1. #define MAX_CARRE 50
  3.         key_t cle;
  4. long* pseg;
  8.      // FTOK => Preparation de la clef pour ouvrir la memoire partagee  
  9. cle = ftok("pere.c",1);
  10. if (cle == -1)
  11.  tt_err("\n\t CLE shm impossible",-1);
  13. // SHMGET => ouverture de la memoire partagee
  14. shmid = shmget(cle,(sizeof(long)*MAX_CARRE),0);
  15. if (shmid == -1)
  16.  tt_err("\n\t SHMGET impossible ",-1);
  18. // SHMAT => Attacnehement du segment memoire au pointeur pseg  
  19. pseg = (long*)shmat(shmid,0,SHM_RDONLY);


 
 
Ce pere lance la creation d'un fils qui s'execute sur un autre code.
Dans le fils je fais :
 

Code :
  1. #define MAX_CARRE 50
  3.         key_t cle;
  4. long* pseg;
  7. // FTOK => Preparation de la clef pour ouvrir la memoire partagee  
  8. cle = ftok("pere.c",1);
  9. if (cle == -1)
  10.  tt_err("\n\t CLE shm impossible",-1);
  12. // SHMGET => ouverture de la memoire partagee
  13. shmid = shmget(cle,(sizeof(long)*MAX_CARRE),IPC_CREAT|0600);
  14. if (shmid == -1)
  15.  tt_err("\n\t SHMGET impossible ",-1);
  17. // SHMAT => Attacnehement du segment memoire au pointeur pseg  
  18. pseg = (long*)shmat(shmid,0,0);


 
Ensuite quand j'essais de mettre en memoire une donnee de type long pour ensuite la lire cote pere, je ne retrouve pas mes petits.
J'ai mis en place des printf pour debugger et OH horreur ....
les adresses memoires pointes par pseg cote fils ne sont pas les meme que cote pere..... comment ce fait ce ????
 
voici une copie des printf cote fils

Code :
  1. printf("\n\t F1 cle %p\n",cle);
  2. printf("\n\t F1 shmid %d\n",shmid);
  3. printf("\n\t F1 Segmem %p\n",pseg);


 
voici une copie des printf cote pere  
 

Code :
  1. printf("\n\t PERE cle %p\n",cle);
  2. printf("\n\t PERE shmid %d\n",shmid);
  3. printf("\n\t PERE Segmem %p\n",pseg);


 
LEs clefs sont identiques, les shmid aussi, mais pas l'aderesse pointee par pseg.....
 
Helpppppppppppppppppppppppppppppp
je m'arrache les cheveux ... deja que je n'en ai plus des masses :-)
 
Dans tous mes modules j'ai les includes quivants
 

Code :
  1. #include<sys/ipc.h>
  2. #include<sys/shm.h>


 
Derniere info, je travaille sur une knoppix bootable depuis un CD...
Je ne sais pas si ca importe beaucoup, mais au cas ou ...
 
 
 
MErci pour votre aide

Reply

Marsh Posté le 08-03-2005 à 14:41:12   

Reply

Marsh Posté le 08-03-2005 à 20:28:49    

Ce n'est pas parce que deux adresses sont differentes dans les address space de tes deux process qu'elles ne pointent pas vers la meme chose. C'est le principe de shmat. Ecrit quelque chose a un offset donne depuis un des process, lit au meme offset dans l'autre process, tu verra que tu lis ce qui a ete ecrit. Meme si les adresses sont differentes.

Reply

Marsh Posté le 09-03-2005 à 07:06:59    

Personnellement, je donnerais à "ftok" les paramètres "." et "getuid()".
Ca te permet d'avoir deux programmes où la clef dépend essentiellement de leur emplacement et de la personne qui exécute. Mais cela ne change rien à ton programme qui est correct.
 
Donc, pour suivre les conseils de Matafan, il te suffit dans le fils, d'écrire "pseg[0]=12345" et dans le père, d'écrire "printf("%ld\n", pseg[0]) et tu verras que tu obtiendras "12345"


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 11-03-2005 à 13:31:17    

Hello Matafan et sve@r
 
Merci pour vos reponses.
Donc si je resume bien tes propos Matafan, je ne sois pas tenir compte de l'adresse pointee par pseg, enfin son contenu. Dans tous les cas de figures ils pointent physiquement vers la meme case memoire ( enfin la meme plage )
 
C'est un peu surprenant , mais bon, le tout c'est de la savoir :-)
 
Par contre ce que tu me dis sve@r je l'ai deja essaye et ca ne marche po.
 
En revanche je me suis refais un tout petit programme qui fonctionne bien si j'ai pseg qui pointe sur des entiers, par contre ca ne marche plus quand ca pointe sur des longs.... Dieu de dieu que ca me fatigue :-)))  mais bon comme je ne suis pas de nature a me laisser faire par une machine, j'irai jusqu'a la fin des choses.....
 
En tout cas milles mercis pour vos reponses.
 
Bonne journee

Reply

Marsh Posté le 11-03-2005 à 20:51:38    

titof13 a écrit :

Hello Matafan et sve@r
 
Merci pour vos reponses.
Donc si je resume bien tes propos Matafan, je ne sois pas tenir compte de l'adresse pointee par pseg, enfin son contenu. Dans tous les cas de figures ils pointent physiquement vers la meme case memoire ( enfin la meme plage )
 
C'est un peu surprenant , mais bon, le tout c'est de la savoir :-)
 
Par contre ce que tu me dis sve@r je l'ai deja essaye et ca ne marche po.
 
En revanche je me suis refais un tout petit programme qui fonctionne bien si j'ai pseg qui pointe sur des entiers, par contre ca ne marche plus quand ca pointe sur des longs.... Dieu de dieu que ca me fatigue :-)))  mais bon comme je ne suis pas de nature a me laisser faire par une machine, j'irai jusqu'a la fin des choses.....
 
En tout cas milles mercis pour vos reponses.
 
Bonne journee


 
Tiens, ça marche avec des entiers. Et avec des "float" ? C'est intéressant d'essayer. Et aussi au lieu d'écrire "pseg[0]=12345", essaye plutôt "pseg[0]=12345L"


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 11-03-2005 à 23:19:45    

C'est d'autant plus bizarre qu'en 32 bit les long ont la meme taille que les int... A mon avis tu a fais une connerie ailleurs.

Reply

Marsh Posté le 17-03-2005 à 07:32:15    

Dsl de vous deranger mais pkoi ne pas utilisé un mmap() en MAP_SHARED + des pthread_mutex_lock/unlock sur un pthread_mutex_t global  ?
 
‰Ô¥

Reply

Marsh Posté le 17-03-2005 à 22:53:44    

plofplof a écrit :

Dsl de vous deranger mais pkoi ne pas utilisé un mmap() en MAP_SHARED + des pthread_mutex_lock/unlock sur un pthread_mutex_t global  ?
 
‰Ô¥


 
Paske titof veut utiliser les shm. Ptet qu'il bosse sur un système où les pthread ne sont pas implémentés. Tout le monde ne bosse pas que sur du Linux...


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 17-03-2005 à 22:55:13    

plofplof a écrit :

Dsl de vous deranger mais pkoi ne pas utilisé un mmap() en MAP_SHARED + des pthread_mutex_lock/unlock sur un pthread_mutex_t global  ?
 
‰Ô¥


parce que ca n'a rien a voir ? [:petrus75]


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 17-03-2005 à 23:08:33    

chrisbk a écrit :

parce que ca n'a rien a voir ? [:petrus75]


Vi, c'est aussi pour ça...  :D


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 17-03-2005 à 23:08:33   

Reply

Marsh Posté le 18-03-2005 à 04:40:47    

Citation :


Paske titof veut utiliser les shm. Ptet qu'il bosse sur un système où les pthread ne sont pas implémentés. Tout le monde ne bosse pas que sur du Linux...  


 
ok bon,
CreateThread() sous windows
pthread_* sous Linux, Darwin, FreeBSD, OpenBSD etc etc etc...
 
Et comment ça ca n'a rien a voir ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed