IPC sous Unix

Version imprimable

17/08/2009, 17h13
Ashin

IPC sous Unix

Bonjour,

J’aimerai savoir quel type d’IPC utiliser pour mon application. Je m’explique :

J’ai deux applis qui actuellement communiquent par queues de messages (sysV) et j’aimerais changer le types d’IPC afin de gagner en vitesse sans toutefois perdre en stabilité. Les données échangées ne dépassent pas 3950 octets.

La première appli démarre puis se forke, ensuite le fils créé plusieurs messages queues fait son taff, supprime les queues puis meurt, le père reforke le nouveau fils créé plusieurs queues …

Qu’en pensez vous ??
Merci

edit: systèmes: RHEL 4 et Solaris 8
18/08/2009, 19h42
Ashin

les IPC n'intéressent personne :roll:
19/08/2009, 08h30
Sve@r

Citation:

Envoyé par Ashin

La première appli démarre puis se forke, ensuite le fils créé plusieurs messages queues fait son taff, supprime les queues puis meurt, le père reforke le nouveau fils créé plusieurs queues …

Si les data ne sont traitées que par un même fils, pas besoin d'IPC.

Maintenant, si les msq sont trop longues pour toi et que ton souci est la rapidité, alors te faut utiliser les shm.
En fait, le seul avantage d'une msq c'est qu'il y a un identificateur numérique permettant un certain type de sélection. Tu peux entrer une data numéro 1, une data numéro 2, une autre numéro 2 et une 4° numéro 1, si tu demandes ensuite les numéro 1 tu récupèreras la 1° et la 4°.
Un autre avantage (qui peut aussi ne pas l'être selon la façon de voir) est qu'une data récupérée est automatiquement effacée.

Avec la shm, tu places simplement des octets dans une map que tu viens lire quand tu veux. C'est ce qu'il y a de plus rapide. Généralement on la couple avec un sem pour éviter les accès concurrents mais si t'en as pas besoin...
19/08/2009, 09h09
Ashin

je me suis mal exprimé, en fait le fils créé des queues pour communiquer non pas avec son père mais avec un autre process. Le père est seulement là en cas de problème (lors de la comm ou autre) et que le fils se plante.

donc en gros, pour simplifier ça revient à deux process qui communiquent par mq
19/08/2009, 18h49
Sve@r

Citation:

Envoyé par Ashin

je me suis mal exprimé, en fait le fils créé des queues pour communiquer non pas avec son père mais avec un autre process. Le père est seulement là en cas de problème (lors de la comm ou autre) et que le fils se plante.

donc en gros, pour simplifier ça revient à deux process qui communiquent par mq

Ok. Ben ils peuvent communiquer aussi
- par socket mémoire => le père crée la socket et chaque fils lit ou écrit le coté qui va bien
- par socket fichier => idem
- par shm => le père crée la shm et chaque fils la rattache à un pointeur perso puis ensuite les fils y vont allègrement à coup de memcpy()
19/08/2009, 22h23
Ashin

actuellement j'hésite entre socket local et pipe nommé (FIFO) qui sont moins lourds
19/08/2009, 22h27
Sve@r

Citation:

Envoyé par Ashin

actuellement j'hésite entre socket local et pipe nommé (FIFO) qui sont moins lourds

Sûrement pas. Les pipes nommés (fichier de type "p") nécessitent un accès disque. Ils ne sont certainement pas "moins lourds" que les pipes mémoire (surtout si tu prépares bien ton truc, avec une structure permettant de manipuler facilement le pipe...)
Et ces deux outils étant contrôlés par le noyau (verrouillage des processus jusqu'à synchronisation), consomment forcément du temps cpu (temps utilisé pour le contrôle), temps qui n'est pas consommé par les shm puisque celles-ci ne sont pas contrôlées (tu parlais au début de rapidité...)
19/08/2009, 22h33
Ashin

oui mais on ne peut pas utiliser les pipes mémoires s'ils n'ont pas la même racine, non ?
19/08/2009, 23h20
Sve@r

Citation:

Envoyé par Ashin

oui mais on ne peut pas utiliser les pipes mémoires s'ils n'ont pas la même racine, non ?

Exact. Mais la shm est accessible par tout le monde (pour peu que chacun connaisse la clef)...
20/08/2009, 00h02
Ashin

je vais tester les shm aussi alors, mais bon s'il faut que je les couple avec des sems, je pense pas être plus rapide que les sockets
20/08/2009, 07h53
Sve@r

Citation:

Envoyé par Ashin

mais bon s'il faut que je les couple avec des sems, je pense pas être plus rapide que les sockets

Ah non. J'ai dit que "généralement" on les couple avec les sem pour éviter les problèmes de data incorrecte (data lue alors qu'un autre process est en train de la modifier) mais si ce cas est peu probable ou pas grave, tu peux très bien éviter les sem !!!