Et c'est quoi le problème ? En quoi offrir une option RMID est-elle mauvaise ?
Houlà, attention je n'ai pas dit que c'était mal, loin de là. Au contraire ca me fait une chouette épine hors du pied comparés aux callbacks en pagaille chez win32 (oui parceque moi et la MFC ca fait 4). J'utilise courament les RMID et j'en suis très content.
Seulement quand on soulève le capot il y a pleins de truc sen dessous quif otn les appels systèmes à ta place pour le tracking. C'ets tout ce que je dis.
Quand on est dan sun thread, même si dans le code on a l'impression que tel thread met un lock et que tel autre réserve la mémoire ce n'est pas tout à fait vrai, en fait pour le MMU c'est le processus qui fait le boulot en nommant les locks, les mutexs et autres pour signaler aux différents threads qui fait quoi. Mais ca n'a pas de cohérence au niveau système, et unthread peut parfaitement retirer le lock posé par un autre thread (même si ca n'est pas recommandé du tout). On perd en fiabilité et en protection, mais en gagne en vitesse et en isolation.
En ce qui concerne la libération de la mémoire allouée, on peut soit créer facilement un compteur de références (vu qu'on est dans le même process c'est pas dur de redéscendre l'info aux threads). Soit se la jouer sagouin et libérer les segments quand le process s'arrette (solution tout à fait acceptable dans pas mal de cas, malgré sont coté gruik). Faire un compteur de références sur de la mémoire partagée n'est pas évident (jette un oeuil sur l'implémentation de RMID). Et un segment partagé n'est pas facilement libérable même quand le dernier process qui l'utilise s'arrette (il aurait plutot tendance à survivre et à rester mappable un moment).
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Houlà, attention je n'ai pas dit que c'était mal, loin de là. Au contraire ca me fait une chouette épine hors du pied comparés aux callbacks en pagaille chez win32 (oui parceque moi et la MFC ca fait 4). J'utilise courament les RMID et j'en suis très content.
Seulement quand on soulève le capot il y a pleins de truc sen dessous quif otn les appels systèmes à ta place pour le tracking. C'ets tout ce que je dis.
Quand on est dan sun thread, même si dans le code on a l'impression que tel thread met un lock et que tel autre réserve la mémoire ce n'est pas tout à fait vrai, en fait pour le MMU c'est le processus qui fait le boulot en nommant les locks, les mutexs et autres pour signaler aux différents threads qui fait quoi. Mais ca n'a pas de cohérence au niveau système, et unthread peut parfaitement retirer le lock posé par un autre thread (même si ca n'est pas recommandé du tout). On perd en fiabilité et en protection, mais en gagne en vitesse et en isolation.
En ce qui concerne la libération de la mémoire allouée, on peut soit créer facilement un compteur de références (vu qu'on est dans le même process c'est pas dur de redéscendre l'info aux threads). Soit se la jouer sagouin et libérer les segments quand le process s'arrette (solution tout à fait acceptable dans pas mal de cas, malgré sont coté gruik). Faire un compteur de références sur de la mémoire partagée n'est pas évident (jette un oeuil sur l'implémentation de RMID). Et un segment partagé n'est pas facilement libérable même quand le dernier process qui l'utilise s'arrette (il aurait plutot tendance à survivre et à rester mappable un moment).