Je pense qu'utiliser des processus communiquant via des POSIX shm est aussi efficace que les threads
A mon sens ça ne sert pas à la même chose. La synchronisation de processus sensibles vai shm relève assez vite du cauchemar par exemple, le nombre de couches à traverser entre la demande d'accès à une info et la lecture de l'info est très largement supérieure également. Ceci étant shm est très rapide pour peux que els mutex/semaphores soient bien codées.
et élimine certains bugs difficiles à cerner
Ca en pose également pas mal d'autre. Tout d'abord les problèmes de droits en lecture/écritue/execution sur le segment partagé. Ensuite tous les problèmes d'accès à la ressource partagée et pour finir les bugs les plus complexes à cerner (les conditions de couses - racing conditions-rendues bizarres pour cause d'appel au système pendant la determination de la dispo) sont présents dans un cas comme dans l'autre.
(notamment quand un thread modifie par inadvertance, via un pointeur, les données privées d'un autre thread)
En théorie ce genre de choses ne devraient pas se produire si le code a été bien fait. Il vaut mieux créer un pool de variables appartenant au process père et laisser les threads taper dedans via un système de lock. Si deux threads commencent à s'échanger des infos directement, neuf fois sur dix on va dans le mur.
[^] # Re: vs POSIX shared memory
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 4.
A mon sens ça ne sert pas à la même chose. La synchronisation de processus sensibles vai shm relève assez vite du cauchemar par exemple, le nombre de couches à traverser entre la demande d'accès à une info et la lecture de l'info est très largement supérieure également. Ceci étant shm est très rapide pour peux que els mutex/semaphores soient bien codées.
et élimine certains bugs difficiles à cerner
Ca en pose également pas mal d'autre. Tout d'abord les problèmes de droits en lecture/écritue/execution sur le segment partagé. Ensuite tous les problèmes d'accès à la ressource partagée et pour finir les bugs les plus complexes à cerner (les conditions de couses - racing conditions-rendues bizarres pour cause d'appel au système pendant la determination de la dispo) sont présents dans un cas comme dans l'autre.
(notamment quand un thread modifie par inadvertance, via un pointeur, les données privées d'un autre thread)
En théorie ce genre de choses ne devraient pas se produire si le code a été bien fait. Il vaut mieux créer un pool de variables appartenant au process père et laisser les threads taper dedans via un système de lock. Si deux threads commencent à s'échanger des infos directement, neuf fois sur dix on va dans le mur.