Dans le cas d'un process qui fork tout de suite après sa création et qui met toutes les données partagées dans des shm, aucune donnée n'est inutilement dupliquée. En + on peut mettre les données partagées en read-only dans un shm à part, qui ne sera pas modifiable par les process lecteurs (et sans ralentir l'accès à ces données).
Ca c'est la theorie, en pratique le faire est extremement complexe, exemple simple: tu partages des structures contenant des pointeurs.
Tu dois t'assurer que ces pointeurs pointent tous dans des segments de memoire partagee, bref il te faut te taper une couche supplementaire au niveau des allocations, operations sur pointeurs,... pour etre sur qu'elles sont prises au bonne endroit, sans parler du risque d'erreur qui causera un AV, voire un eventuel trou de securite selon les cas.
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ? Il faut savoir que le segment n'est plus utilise du tout, donc il faut suivre toutes les allocations et s'assurer que le segment est completement vide, etc... Sinon tu gardes tous tes segments sans jamais les releaser et bonjour le bordel.
Idem pour la synchro, si tu utilises des threads, tu peux te contenter de spin-locks qui n'entrainent pas de context-switch, alors qu'avec des processus differents, soit tu dois gerer l'allocation de ces spin-locks sur de la memoire partagee(et selon les implementations c'est pas gagne, cf. critical sections de Windows par exemple), soit c'est le mutex, qui est bien plus couteux.
Les processus qui utilisent des segments de memoire partagee c'est pratique dans certains cas mais c'est _tres tres_ loin de remplacer les threads.
[^] # Re: vs POSIX shared memory
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 7.
Ca c'est la theorie, en pratique le faire est extremement complexe, exemple simple: tu partages des structures contenant des pointeurs.
Tu dois t'assurer que ces pointeurs pointent tous dans des segments de memoire partagee, bref il te faut te taper une couche supplementaire au niveau des allocations, operations sur pointeurs,... pour etre sur qu'elles sont prises au bonne endroit, sans parler du risque d'erreur qui causera un AV, voire un eventuel trou de securite selon les cas.
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ? Il faut savoir que le segment n'est plus utilise du tout, donc il faut suivre toutes les allocations et s'assurer que le segment est completement vide, etc... Sinon tu gardes tous tes segments sans jamais les releaser et bonjour le bordel.
Idem pour la synchro, si tu utilises des threads, tu peux te contenter de spin-locks qui n'entrainent pas de context-switch, alors qu'avec des processus differents, soit tu dois gerer l'allocation de ces spin-locks sur de la memoire partagee(et selon les implementations c'est pas gagne, cf. critical sections de Windows par exemple), soit c'est le mutex, qui est bien plus couteux.
Les processus qui utilisent des segments de memoire partagee c'est pratique dans certains cas mais c'est _tres tres_ loin de remplacer les threads.