Et dérrière il faut quand même vérifier qu'un des processus partageant c'ets aps amusé à mettre un lock exclusif ou en lecture seule sur le segment partagé.
Euh, c'est dans quelle version de POSIX ces "locks" qu'il faut vérifier même après l'attachement ? Les sémaphores sont optionels (et sont souvent remplaçables par des signaux).
Exemple simple: un père crée un ou 2 segments, éventuellement ré-attache un des 2 segments en read-only après l'avoir rempli. Fork(s). Tous les fils héritent alors de chaque segment partagé comme faisant partie de leur propre mémoire. L'éventuel flag read-only est déjà positionné dans le hardware par le père. Il n'y a plus jamais de test des droits d'accès par l'OS (l'attachement a déjà effectué par le père). Donc aucun ralentissement par rapport à un thread, qui ne propose même pas ce flag read-only hardware.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Euh, c'est dans quelle version de POSIX ces "locks" qu'il faut vérifier même après l'attachement ? Les sémaphores sont optionels (et sont souvent remplaçables par des signaux).
Exemple simple: un père crée un ou 2 segments, éventuellement ré-attache un des 2 segments en read-only après l'avoir rempli. Fork(s). Tous les fils héritent alors de chaque segment partagé comme faisant partie de leur propre mémoire. L'éventuel flag read-only est déjà positionné dans le hardware par le père. Il n'y a plus jamais de test des droits d'accès par l'OS (l'attachement a déjà effectué par le père). Donc aucun ralentissement par rapport à un thread, qui ne propose même pas ce flag read-only hardware.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.