Mémoire Pool vs malloc

Question

Je passais en revue quelques spécifications de système d'exploitation en temps réel et j'ai lu que dans RTOS, nous ne préférons généralement pas utiliser malloc. La raison de ceci a été donnée comme: pour le problème de performance, nous ne devrions pas utiliser malloc car il prend beaucoup de temps pour allouer de la mémoire via malloc et aussi pour avoir plus de mémoire allouée.

Maintenant Dans les systèmes en temps réel, la contrainte de temps est présente avec tous les processus, nous n'utilisons généralement pas malloc. J'ai été curieux et j'ai commencé à chercher un peu comment la mémoire est réellement allouée à l'exécution dans RTOS et j'ai trouvé des pools de mémoire. Maintenant, il a été écrit que les pools de mémoire signifie en réalité que l'allocation de blocs de taille fixe. Maintenant, les avantages des pools de mémoire est qu'il ne souffre pas de la fragmentation. Comment est-ce possible? Supposons que nous ayons 3 pools de 4 octets et que l'application nécessite 10 octets, dans ce cas, les pools de mémoire souffriront d'une fragmentation interne.

Comment fonctionnent les pools de mémoire et comment la mémoire est allouée? Est-ce que les applications obtiennent les pools au moment de la compilation, comme une application particulière aura 3 pools à partir de la taille du pool de 4 octets? Et s'ils ont besoin de mémoire qui ne peut pas tenir dans les piscines. De nombreux pools de mémoire de différentes tailles sont-ils présents dans un tel système? S'il vous plaît expliquez-moi.

Answer 1

Eh bien, la fragmentation dépend de l'implémentation du pool de mémoire. Généralement, un pool de mémoire est un pool de blocs de mémoire de taille fixe. quand quelque chose veut un bloc de mémoire de cette taille, il va à ce pool. Ainsi, il n'y a pas de fragmentation car tout ce qui veut un bloc de cette taille l'obtient à partir d'un pool de blocs de cette taille.

Maintenant, si un groupe de blocs d'une taille particulière n'existe pas, un pool de plus grande taille peut être utilisé. Si cela se produit alors techniquement il y a fragmentation parce qu'une certaine partie du bloc mémoire allouée n'est pas utilisée (fragmentée).

Si tous les pools de mémoire fournissaient des blocs de toutes les tailles requises, il n'y aurait pas de fragmentation.

Answer 2

Les pools n'éliminent pas la fragmentation, mais ils peuvent la réduire considérablement et éventuellement réduire le temps système d'allocation d'un très grand nombre de très petits blocs. Un bon schéma est une bibliothèque qui permet au code client de créer un pool pour chacune de ses structures hautement échelonnées. Lors de la création du pool, vous spécifiez la taille du bloc, le nombre de blocs à allouer initialement et à augmenter, ainsi qu'un nom de texte pour le débogage.

Pour allouer un bloc, transmettez l'ID du pool à l'allocateur. Chaque fois que le pool n'a pas de blocs libres, il alloue un bloc contigu de blocs et les rend disponibles, en renvoyant l'un d'entre eux. Chaque fois qu'un bloc est libéré, si tous les blocs du bloc sont libres, cela libère le bloc. Pour déboguer, il y a une routine qui imprime tous les pools, en donnant la description, le nombre alloué et éventuellement d'autres statistiques comme le nombre de free disponibles (si c'est élevé, il y a des problèmes de fragmentation) et le maximum jamais alloué . Très utile pour trouver des fuites de mémoire.

Le pire des cas pour ce type de bibliothèque concerne un sous-système qui alloue un grand nombre de blocs et en libère une majorité aléatoire au début de la vie du système. Beaucoup de morceaux resteront alloués mais avec peu de blocs en cours d'utilisation. Le meilleur des cas (comparé à malloc) est avec le cycle continu de besoin de nouveaux blocs avec des durées de vie très variables, pour les systèmes qui doivent rester pendant de longues durées, comme certains systèmes embarqués.

Ceci est plus simple et fonctionne mieux pour les applications monothread. Pour les applications multithreads, il faut veiller à ce que les threads soient sûrs, et vous devrez peut-être imiter les optimisations que malloc() fait souvent sous les couvertures pour minimiser le surdébit de verrouillage (par exemple, arenas par thread).