Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :)
Pas du tout, PBPG dit juste qu'on ne peut pas gérer 20 000 handles SHM initialisés avec un malloc standard. C'est une question purement théorique vu que le mmu est limité à 4096 segments partagés de toute façon (en archi x86, je doute que ce soit beaucoup plus sur les autres archis). Donc la question en se pose pas. Mais si elle se posait il aurait probablement raison.
Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
En SHM ca n'est pas évident du tout. Il faut soit passer par des ID ayants des droits très différents et transférant ces droits aux processes qui le réclament (mais là on ne peut pas sous-allouer) ou alors créer un système pseudo-lock sur un sous segment et s'assurer que seul le processus qui a fait la demande de sous allocation peut lever ce lock. Mais là on est plus en mode de protection hardware et techniquement du point de vue kernel/mmu tout les process qui ont accès à ce segment de mémoire partagée peuvent faire sauter le pseudo-lock. Là on est exactement dans le même cas que dans les threads ou le lock est purement informatif et non portecteur.
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
CF plus haut, dans ce cas tu perds forcément la protection mmu si chère à ton coeur
Alors tu utilises forcément un spinlock,
GNI ??? Un spinlock n'est pas un lock, c'est un méccanisme d'attente en attendant la libération d'une ressource , il faut faire un vrai lock dérrière si on veut "protéger" la ressource, ou s'assurer que els manips que l'on fait aprés le succès du spinlock sont atomiques. Dans 99.99% des cas ça oblige à coder en assembleur des instructions très précise dépendante du CPU (donc niveau portabilité ....). La pose de lock par un processus (et j'admets que c'ets un vrai lock, certifié par le hardware et/ou le kernel) nécessite plusieurs appels systèmes. La pose de lock par un thread sur un segment de la mémoire du processus (et j'admet que c'ets un lock informatif que n'importe quel autre thread peut gicler) n'en consomme pas forcément.
Sache que le principe des spinlocks fonctionne exactement pareil dans un shm
Pas du tout, un spinlock process est un while(1) ou équivalent. Un pthread_spinlock est un event catcher. Si l'évènement ne c'est pas présenté le thread passe la main au thread suivant. Ca change beaucoup de choses.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Du point de vue des pages tables c'est clair, c'est juste de la mémoire allouée dont un processus se sert. Par contre du point de vue du système ca n'a rien à voir.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Pas du tout, PBPG dit juste qu'on ne peut pas gérer 20 000 handles SHM initialisés avec un malloc standard. C'est une question purement théorique vu que le mmu est limité à 4096 segments partagés de toute façon (en archi x86, je doute que ce soit beaucoup plus sur les autres archis). Donc la question en se pose pas. Mais si elle se posait il aurait probablement raison.
Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
En SHM ca n'est pas évident du tout. Il faut soit passer par des ID ayants des droits très différents et transférant ces droits aux processes qui le réclament (mais là on ne peut pas sous-allouer) ou alors créer un système pseudo-lock sur un sous segment et s'assurer que seul le processus qui a fait la demande de sous allocation peut lever ce lock. Mais là on est plus en mode de protection hardware et techniquement du point de vue kernel/mmu tout les process qui ont accès à ce segment de mémoire partagée peuvent faire sauter le pseudo-lock. Là on est exactement dans le même cas que dans les threads ou le lock est purement informatif et non portecteur.
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
CF plus haut, dans ce cas tu perds forcément la protection mmu si chère à ton coeur
Alors tu utilises forcément un spinlock,
GNI ??? Un spinlock n'est pas un lock, c'est un méccanisme d'attente en attendant la libération d'une ressource , il faut faire un vrai lock dérrière si on veut "protéger" la ressource, ou s'assurer que els manips que l'on fait aprés le succès du spinlock sont atomiques. Dans 99.99% des cas ça oblige à coder en assembleur des instructions très précise dépendante du CPU (donc niveau portabilité ....). La pose de lock par un processus (et j'admets que c'ets un vrai lock, certifié par le hardware et/ou le kernel) nécessite plusieurs appels systèmes. La pose de lock par un thread sur un segment de la mémoire du processus (et j'admet que c'ets un lock informatif que n'importe quel autre thread peut gicler) n'en consomme pas forcément.
Sache que le principe des spinlocks fonctionne exactement pareil dans un shm
Pas du tout, un spinlock process est un while(1) ou équivalent. Un pthread_spinlock est un event catcher. Si l'évènement ne c'est pas présenté le thread passe la main au thread suivant. Ca change beaucoup de choses.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Du point de vue des pages tables c'est clair, c'est juste de la mémoire allouée dont un processus se sert. Par contre du point de vue du système ca n'a rien à voir.