exemple simple: tu partages des structures contenant des pointeurs.
2 solutions:
1. Tu utilises des pointeurs relatifs à l'intérieur d'un gros segment.
2. Les segments partagés ont été créé dans un père: tout le monde a donc les exactement les memes adresses absolues pour toutes les zones mémoires partagées (et pour tout ce qui était alloué dans le père d'ailleurs).
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Allocation des spin-locks: voir les 2 solutions ci-dessus. On peut noter que avoir à boucler et consommer du CPU pour éviter un appel système qui lui ne consomme pas de cpu quand il bloque, c'est de toutes façons une situation qu'il vaut mieux éviter dans un algo.
Je suis d'accord pour dire que des outils supplémentaires sont à utiliser en + de l'API Posix, si on veut se simplifier shm.
Par contre je ne vois pas quels outils vont empecher efficacement une thread de lire ou modifier, via un mauvais pointeur, les données privées d'une autre thread.
Ni comment imposer efficacement à une thread que telle zone mémoire ne lui est accessible qu'en lecture.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
2 solutions:
1. Tu utilises des pointeurs relatifs à l'intérieur d'un gros segment.
2. Les segments partagés ont été créé dans un père: tout le monde a donc les exactement les memes adresses absolues pour toutes les zones mémoires partagées (et pour tout ce qui était alloué dans le père d'ailleurs).
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Allocation des spin-locks: voir les 2 solutions ci-dessus. On peut noter que avoir à boucler et consommer du CPU pour éviter un appel système qui lui ne consomme pas de cpu quand il bloque, c'est de toutes façons une situation qu'il vaut mieux éviter dans un algo.
Je suis d'accord pour dire que des outils supplémentaires sont à utiliser en + de l'API Posix, si on veut se simplifier shm.
Par contre je ne vois pas quels outils vont empecher efficacement une thread de lire ou modifier, via un mauvais pointeur, les données privées d'une autre thread.
Ni comment imposer efficacement à une thread que telle zone mémoire ne lui est accessible qu'en lecture.