Je reprend ici la discussion avec pbpg sur les bugs malloc, interrompue par la mise en page un peu plus haut:
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free
Faux. Dans le cas des threads, avant de faire un free il faut s'assurer qu'aucune thread ne s'en servira plus jamais.
Dans le cas de shm, le process qui détache doit seulement s'assurer que lui ne s'en servira jamais.
(free reel dans le cas multithread, wrapper free dans le cas shm)
N'importe quoi. Free et malloc sont des bibliothèques C qui utilisent de temps en temps l'appel système brk pour faire varier la limite du tas de une ou plusieurs pages.
Shm est un appel système qui alloue (ou désalloue quand plus aucun process n'attache) exactement le nombre de pages dont on a besoin.
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
C'est carrément très discutable !
D'abord un process sans thread peut utiliser malloc comme il le veut pour ses variables privées. Et il a la garantie qu'aucun autre process ne viendra y accéder, contrairement aux threads qui peuvent mélanger leurs variables privées.
Pour les variables partagées shm, il faut juste faire attention à ne pas gaspiller le contenu des pages encore attachées (gaspillage qui ne peut pas se produire si on évite de créer et détruire plein de fois des petits objets partagés de tailles différentes, ce qui serait couteux en temps CPU). Quand on détache ces pages, on ne déclenche pas de bugs dans les autres proces, et elles seront libérées automatiquement quand tout le monde les aura détaché..
Si vraiment on tient à créer et détruire plein de fois des petits objets partagés dans le même segment shm (pourquoi ?) , on peut réutiliser la majeure partie du code LGPL de malloc dans la glibc.
Ces petits gaspillages facilement évitables sont beaucoup moins grave que le problème déjà évoqué pour les threads: libérer par free une zone mémoire peut entrainer des bugs siliencieux et donc très pervers.
[^] # malloc bugs pour threads, voir plus haut
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free
Faux. Dans le cas des threads, avant de faire un free il faut s'assurer qu'aucune thread ne s'en servira plus jamais.
Dans le cas de shm, le process qui détache doit seulement s'assurer que lui ne s'en servira jamais.
(free reel dans le cas multithread, wrapper free dans le cas shm)
N'importe quoi. Free et malloc sont des bibliothèques C qui utilisent de temps en temps l'appel système brk pour faire varier la limite du tas de une ou plusieurs pages.
Shm est un appel système qui alloue (ou désalloue quand plus aucun process n'attache) exactement le nombre de pages dont on a besoin.
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
C'est carrément très discutable !
D'abord un process sans thread peut utiliser malloc comme il le veut pour ses variables privées. Et il a la garantie qu'aucun autre process ne viendra y accéder, contrairement aux threads qui peuvent mélanger leurs variables privées.
Pour les variables partagées shm, il faut juste faire attention à ne pas gaspiller le contenu des pages encore attachées (gaspillage qui ne peut pas se produire si on évite de créer et détruire plein de fois des petits objets partagés de tailles différentes, ce qui serait couteux en temps CPU). Quand on détache ces pages, on ne déclenche pas de bugs dans les autres proces, et elles seront libérées automatiquement quand tout le monde les aura détaché..
Si vraiment on tient à créer et détruire plein de fois des petits objets partagés dans le même segment shm (pourquoi ?) , on peut réutiliser la majeure partie du code LGPL de malloc dans la glibc.
Ces petits gaspillages facilement évitables sont beaucoup moins grave que le problème déjà évoqué pour les threads: libérer par free une zone mémoire peut entrainer des bugs siliencieux et donc très pervers.