1) Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
2) Tu alloues des petits blocs memoire a l'interieur de ces gros blocs pour utilisation habituelle
3) Tu utilises la memoire allouee
4) Tu liberes les petits blocs quand tu n'en as plus besoin
5) Tu tient une comptabilite des blocs pour savoir quand toutes les allocations d'un gros bloc ont ete liberees
6)Quand toutes les allocations d'un gros bloc ont ete liberees, le gros bloc peut etre desalloue
Cas thread:
1) 5) et 6) sont pris en charge automatiquement par malloc/free, le soft lui-meme n'a qu'a faire 2) et 4) en utilisant malloc/free
cas shm:
Tu dois tout refaire a la main car la heap ne supporte pas les segments de memoire partagee
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.
C'est faux, exemple tres simple :
- Un segment partage de 64Ko est utilise par plusieurs process pour les allocations partagees
- Process A fait une allocation de 30 bytes dans ce segment, remplit le buffer et l'envoie a B
- Process B fait une operation sur le buffer, le met de cote pour faire autre chose, et va revenir a ce buffer plus tard
- Au bout d'un moment, process A libere l'allocation car lui n'en a plus besoin
- Process A fait une _autre_ allocation pour une autre operation, et par malchance celle ci se retrouve par dessus l'allocation precedente(possible car cette zone memoire est marquee comme libre vu qu'elle a ete liberee)
- Process A ecrit qqe chose dans cette allocation
- Process B qui a toujours un pointeur sur le buffer du debut le lit, et y trouve n'importe quoi --> il plante
C'est _exactement_ le meme probleme qu'avec les threads.
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.
Oui, ca devient le cas super ou tu te retrouves avec des pointeurs situes dans 2 mondes totalement differents et qu'il faut etre sur que tu ne passes pas un pointeur de ton propre espace a un autre processus ==> risque de bugs supplementaire
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.
Pourquoi ? Parce que si ton soft partage des objets qui font 32 bytes, t'as pas envie de gaspiller une page entiere a chaque fois car ca devient une utilisation en RAM monstrueuse(sans parler du cout CPU de devoir ouvrire une shm pour chaque allocation).
Quand a reutiliser la majeure partie du code de malloc/free, t'as pas idee de la complexite des ces elements et du cout que cela implique de devoir les modifier, sans parler du risque d'introduire des bugs la aussi.
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.
Ces gaspillages sont enormes si tu n'utilises pas le meme segment pour plusieurs allocation et la complexite de l'operation dans son ensemble rend les risques de bugs bien plus eleve qu'avec les threads.
Serieusement, je suis persuade que tu n'as jamais essaye de developper un soft un tant soit peu complexe avec les shm, il est plus qu'evident qu'ils ne sont pas un remplacement realiste aux threads apres un minimum d'utilisation. Ils ont une utilite mais ce n'est pas de remplacer l'architecture a base de threads, c'est pas fait pour.
[^] # Re: malloc bugs pour threads, voir plus haut
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Il y a plusieurs etapes :
1) Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
2) Tu alloues des petits blocs memoire a l'interieur de ces gros blocs pour utilisation habituelle
3) Tu utilises la memoire allouee
4) Tu liberes les petits blocs quand tu n'en as plus besoin
5) Tu tient une comptabilite des blocs pour savoir quand toutes les allocations d'un gros bloc ont ete liberees
6)Quand toutes les allocations d'un gros bloc ont ete liberees, le gros bloc peut etre desalloue
Cas thread:
1) 5) et 6) sont pris en charge automatiquement par malloc/free, le soft lui-meme n'a qu'a faire 2) et 4) en utilisant malloc/free
cas shm:
Tu dois tout refaire a la main car la heap ne supporte pas les segments de memoire partagee
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.
C'est faux, exemple tres simple :
- Un segment partage de 64Ko est utilise par plusieurs process pour les allocations partagees
- Process A fait une allocation de 30 bytes dans ce segment, remplit le buffer et l'envoie a B
- Process B fait une operation sur le buffer, le met de cote pour faire autre chose, et va revenir a ce buffer plus tard
- Au bout d'un moment, process A libere l'allocation car lui n'en a plus besoin
- Process A fait une _autre_ allocation pour une autre operation, et par malchance celle ci se retrouve par dessus l'allocation precedente(possible car cette zone memoire est marquee comme libre vu qu'elle a ete liberee)
- Process A ecrit qqe chose dans cette allocation
- Process B qui a toujours un pointeur sur le buffer du debut le lit, et y trouve n'importe quoi --> il plante
C'est _exactement_ le meme probleme qu'avec les threads.
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.
Oui, ca devient le cas super ou tu te retrouves avec des pointeurs situes dans 2 mondes totalement differents et qu'il faut etre sur que tu ne passes pas un pointeur de ton propre espace a un autre processus ==> risque de bugs supplementaire
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.
Pourquoi ? Parce que si ton soft partage des objets qui font 32 bytes, t'as pas envie de gaspiller une page entiere a chaque fois car ca devient une utilisation en RAM monstrueuse(sans parler du cout CPU de devoir ouvrire une shm pour chaque allocation).
Quand a reutiliser la majeure partie du code de malloc/free, t'as pas idee de la complexite des ces elements et du cout que cela implique de devoir les modifier, sans parler du risque d'introduire des bugs la aussi.
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.
Ces gaspillages sont enormes si tu n'utilises pas le meme segment pour plusieurs allocation et la complexite de l'operation dans son ensemble rend les risques de bugs bien plus eleve qu'avec les threads.
Serieusement, je suis persuade que tu n'as jamais essaye de developper un soft un tant soit peu complexe avec les shm, il est plus qu'evident qu'ils ne sont pas un remplacement realiste aux threads apres un minimum d'utilisation. Ils ont une utilite mais ce n'est pas de remplacer l'architecture a base de threads, c'est pas fait pour.