Bonjour,  
 
je suis en train de codé un ensemble de programme déstiné à être intégré dans un robot ( PC Embarqué sous Linux ) et j'ai préféré séparé la fonction global en plusieurs sous systèmes pour une plus grande facilité de débuggage et je l'espère une plus grande stabilité de l'ensemble ( je compte réaliser un petit prog qui surveille l'execution et relance le prog en cas de plantage )
 
Seulement voila, il est venu le temps de faire 'communiquer' les programmes entre eux, il y a une sorte d'architecture client/serveur avec 2 programmes qui jouent le rôle de serveur, et 1 prog qui récupère tous ca.
 
J'ai déja lu quelques trucs sur les IPC & co mais ils s'agient le plus souvent de communication entre thread, avec des processus parents & fils. Mais dans mon cas ils s'agient de processus au lancement completement séparé, mais qui doivent se synchroniser.
 
Donc pour cela j'avais pensser faire comme cela, dites moi ce que vous en penssez
 
Le serveur ouvre un 'partage' IPC au démarrage et met la clef dans un fichier au nom constant.
Le client ouvre le fichier, recupère le clef, et ouvre  le partage avec cette clef, ensuite il lui suffit d'utiliser les données quand il en a besoin.
 
Les problèmes qui pourrait survenir sont tout d'abord des problèmes d'accès, je ne sais pas ce qu'il adviendrait si cela arrivé ( visiblement il existe pour cela les MUTEX mais je n'ai pas très bien compris, je pensse que je vais chercher un peu de doc la dessus ), et d'autre part, il n'y aurait pas plus simple? Je me suis dis intuitivement que pour communiquer entre eux les progs avez besoin d'un point fixe ( le fichier ), mais je ne sais pas si c'est exact et s'il n'y a pas d'alternative plus simple voir plus sure a mettre en oeuvre.
 
Qu'en penssez vous ( et désolé pour le pavé )

La troisième porte à gauche après la cuisine, la lumière est sur la droite à l'intérieur.
http://forum.hardware.fr/hardwaref [...] _sujet.htm

 
je me disais que vu qu'il s'agit d'échange interprocessus sous Linux, ca avait surement ca place ici plus que sur prog, mais bon, je me suis ptet tromper ...

J'ai travaillé 3 mois sur un robot sous Linux avec une architecture similaire Je n'ai pas le temps de détailler cet après-midi (je le ferai ce soir si tu le souhaites), mais j'ai fait exactement ce que tu suggères (avec des sémaphores et du partage de mémoire en IPC), et ça marche très très bien. Je ne sais pas si j'ai le droit de te donner mes classes par contre
 
Edit : à la seule différence que la clef était en dur dans le code. C'est une constante pour que la communication se fasse bien, donc je ne vois pas pourquoi l'exporter...

 
 
dans le cours que j'avais la clef était une variable sans l'attribue 'const', donc je l'ai supposée dynamique, mais si l'on peu faire sans, c'est tout aussi bien et ca me permet de virer un accès a un fichier inutile    
 
Un peu moins de code, un peu moins de boggue ...
 
PS: si tu peux m'expliquer simplement comment tu as fait, sans nécessairement me donnée le code ( je suis pas un adepte du tout fait, mais je suis dans une position délicate le code doit être près pour dans 1 semaine, ... mais y a pas que ca[/mylife] ), donc si tu as le temps de m'expliquer, ce serait super

 
OK, je t'explique ça ce soir, sauf imprévu.

Corba peut t'aider.

Là comme ça pour un truc simple j'utiliserais une FIFO placée sur le disque à un endroit idoine (mkfifo est ton ami). Plus sophistiqué, il y a D-BUS, qui est conçu pour la communication entre daemons. Et le must c'est CORBA, mais là c'est plus pour faire des RPC, ce qui me paraît carrément le grand luxe pour ce que tu cherches à faire.

Bon, au boulot
 
Supposons que l'on veuille partager une donnée toto de type Toto : on va pointer dessus, le pointeur donnant sur la zone partagée. Toto ne dois pas être un pointeur, ni un attribut virtuel (impossibles à partager).
 
Définissons une clef pour la mémoire et une pour le sémaphore (ça peut être la même). On stocke les id des ressources partagées dans idMem et idSema.
 

 
Pour pouvoir pointer sur la mémoire, il faut qu'elle soit créée. Le premier processus lancé doit la créer (flag IPC_CREAT), le second n'a pas ce flag.
 

 
Pour libérer la mémoire partagée (par le dernier processus qui finit) :
 

 
Voilà pour la mémoire, y a plus qu'à manipuler toto. Par contre, pour éviter les accès concurrents à la mémoire, il faut ajouter des sémaphores d'exclusion mutuelle.
 
Définissons les opérateurs de verrouillage et libération de l'accès mémoire :
 

 
On initialise les opérateurs :
 

 
On initialise les sémaphores (IPC_CREAT mis ou pas, comme précédemment) :
 

 
Pour se réserver l'accès mémoire :
 

 
Pour le libérer après avoir fait ce qu'on veut avec la ressource :
 

 
Enfin le dernier processus à terminer doit détruire le sémaphore :
 

 
Voilà, l'essentiel est là je crois, y a plus qu'à mettre ça comme tu le sens dans une classe (genre les initialisations dans le constructeur et des méthodes pour bloquer/débloquer les sémaphores etc.)

merci je suis certain que ca en aidera plus d'un

question con: si mais programmes en 'client/serveur', que le serveur est en écriture seule & que le client est lui en lecture seule, ai-je besoin de sémaphore pour réserver l'accès?

 
Certes.

 
Oui, les écritures et lectures ne sont certainement pas des opérations élémentaires.