Et si un pointeur mal programmé essaye de modifier ces données, sigsegv.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
Ce que j'évoquais c'est le nombre d'appels systèmes à faire entre le moment ou un processus essaye de lrie ou d'écrire la mémoire d'un autre et le moment ou l'opération de lecture écriture est terminée.
Dans le cas des threads on est dans le même processus. Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon. Dans le cas de SHM le nombre de traitement est plus improtant, surtout si les segments sont filemapés. Il y en a près d'une trentaine je crois.
Ceci étant je suis un très grand fan de SHM, mais je l'utilise principalement pour me passer complètement des mutex/semaphores sur les applis qui ont besoins d'accéder très souvent a des ressoruces bien définies sur des temps très courts.
[^] # 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é à 2.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
Ce que j'évoquais c'est le nombre d'appels systèmes à faire entre le moment ou un processus essaye de lrie ou d'écrire la mémoire d'un autre et le moment ou l'opération de lecture écriture est terminée.
Dans le cas des threads on est dans le même processus. Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon. Dans le cas de SHM le nombre de traitement est plus improtant, surtout si les segments sont filemapés. Il y en a près d'une trentaine je crois.
Ceci étant je suis un très grand fan de SHM, mais je l'utilise principalement pour me passer complètement des mutex/semaphores sur les applis qui ont besoins d'accéder très souvent a des ressoruces bien définies sur des temps très courts.