• [^] # Re: vs POSIX shared memory, read-only

    Posté par . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.

    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).

    Au niveau du process si il est en user-space je suis d'accord avec toi. Une fois le segment attaché il est là. Mais au niveau du kernel c'est un poil plus complexe, vu qu'il doit quand même faire le mapping mémoire réelle/mémoire virtuelle pour chaque processus (au lieu d'un seul appel dans le cas de threads). En mémoire virtuelle chaque process aura une adresse virtuelle différente pour le segement partagé. Même si le mapping lui même et les droits qui lui sont attribués sont bien gérés en hardware par le mmu (de façon plus ou moins heureuse suivant les architectures), les controles des segments, des locks et des unlocks se fait en externe via des syscall, alors que dans un thread posix une fois la mémoire obtenue tu n'as de compte à rendre à personne sur son utilisation du moment que tu te conformes aux droits demandés à la création.
    En NTPL les locks, mutex et autres se font à l'intérieur du process sans déranger le kernel, ca réduit quand même beaucoup le nombre de syscall qui partent (juste création/changement de droits/destruction).