Pool mémoire

Bonjour,
Je vous propose un sujet sur lequel je me suis penché récemment et qui s'avère intéressant bien que simple.
Il s'agit de créer un pool mémoire. Qu'est-ce donc ?
C'est une large zone de mémoire qu'on alloue dans laquelle on va procéder nous-même aux allocations pour un type de donnée précis.
Il faut donc d'abord avoir un type de donnée que l'on va avoir à allouer plusieurs fois. Exemple :

Code:

typedef
struct
{
  int valeur;
}
Donnee;


Que faire précisément ?
- Allouer un gros bloc de mémoire
- Le préparer pour qu'il soit prêt à accueillir plusieurs objets de type 'Donnee'
- Construire une fonction qui y "alloue" un objet de type 'Donnee' et qui renvoie son adresse ou NULL s'il n'y a plus de place dans le pool
- Construire une fonction qui "libère" un objet
- Enfin, construire une fonction qui libère le bloc de mémoire
Bien entendu, on peut produire quelques variantes mais c'est l'idée générale.

Maintenant, à votre avis, en quoi est-ce utile ?

Ah, dommage... Ce sujet ne semble pas aussi intéressant/simple que je le pensais.

Pourquoi vous êtes ci rapide pour juger le problème le C/C++ permet de redéfinir les fonctions d'allocation/de libération de mémoire new et delete. Donc c'est faisable. J'avais un livre qui traitait cela en Turbo C++ mais j'ai oublié où est-ce que je l'ai caché.

Je ne demande pas de solution ! Je ne fais que proposer cela comme exercice.

Maintenant, à votre avis, en quoi est-ce utile ?

Bon à mon avis, ça sert comme une initiation à l'allocation dynamique de la mémoire. Ca peut se donner comme mini-projet: ré-implémentation des fonctions d'allocation ou désallocation de la mémoire.

non, Timon?

methodiX a écrit:Bon à mon avis, ça sert comme une initiation à l'allocation dynamique de la mémoire.
[...]
non, Timon?

En effet, mais heureusement, ça ne se limite pas qu'à ça !

De plus, on peut gagner la gestion personnalisée de la mémoire
Protéger ses propres zones, partage et swap de mémoire ...

methodiX a écrit:De plus, on peut gagner la gestion personnalisée de la mémoire

Oui, on y gagne par exemple lorsque l'on sait dès le départ combien de données maximum seront allouées à tout instant. Grâce au pool mémoire, on est alors certain que l'allocation réussira. Bien entendu, si on n'en a aucune idée, l'allocation réussira seulement tant que le pool ne sera pas plein.
De plus, il n'y a pas de risque de fragmentation puisque toutes les données ont dans le pool (en général) la même taille. On utilise donc cette zone mémoire au mieux.
Enfin, on profite aussi d'une allocation quasiment instantanée puisqu'on sait précisément (ou presque) où il y a de la place.

Salut Timon:
L'idée m'a beaucoup plu. Cependant, l'histoire de la fragmentation de la mémoire n'a pas été bien abordée. On sera toujours face à un problème de réorganisation de la mémoire, si on fait plusieurs allocations/désallocations de variables dynamiques dans le pool.

non?

Il ne peut pas y avoir fragmentation puisqu'on n'admet l'allocation que d'un type de donnée.
On pourrait considérer qu'il y a fragmentation si on cherche à allouer des tableaux. Or, le pool mémoire n'est pas adapté pour ça. Il me semble que l'on parle sinon de memory chunk.

Qu'appelles-tu "Type de donnée" ? Donner des exemples pour qu'on puisse parler le même langage.

nabiL a écrit:Qu'appelles-tu "Type de donnée" ? Donner des exemples pour qu'on puisse parler le même langage.

J'en ai déjà donné un.

Code:

typedef
struct
{
  int valeur;
}
Donnee;

Le pool mémoire ne contiendra que des objets Donnee.

Et le code ? Ou est-ce qu'il est dans tout cela ?

Quel code manianis?

Timon: int valeur ==> pour stocker quoi? une @mémoire? J'ai pas bien digéré l'histoire. Je suis un peu loin de l'informatique!

methodiX a écrit:Timon: int valeur ==> pour stocker quoi? une @mémoire? J'ai pas bien digéré l'histoire. Je suis un peu loin de l'informatique!

C'est un exemple.
J'aurais pu mettre autre chose. Par exemple, simplement :

Code:

typedef int Donnee;

voire indiquer que la donnée est d'un tout autre type !
Ce qu'est Donnee, on s'en fiche. C'est l'objet lui-même qui importe.
L'objectif est de donner au fur et à mesure des objets de ce type à l'appelant, tant que le pool mémoire le permet.

Si on vous demande d'utiliser le pool de mémoire pour allouer de l'espace pour plusieurs variable V1, V2, ...., Vn, de tailles respectives t1, t2, ..., tn. Comment tu fais?

Le but :

Que faire précisément ?
- Allouer un gros bloc de mémoire
- Le préparer pour qu'il soit prêt à accueillir plusieurs objets de type 'Donnee'
-
Construire une fonction qui y "alloue" un objet de type 'Donnee' et qui
renvoie son adresse ou NULL s'il n'y a plus de place dans le pool
- Construire une fonction qui "libère" un objet
- Enfin, construire une fonction qui libère le bloc de mémoire
Bien entendu, on peut produire quelques variantes mais c'est l'idée générale.

Comme je l'ai déjà dit : le pool mémoire est surtout utilisé pour n'allouer qu'un seul et unique type de donnée. La taille de ce qu'il faut allouer ne peut pas varier. C'est ce qui le rend puissant.
Je crois qu'il va falloir que je donne les prototypes des fonctions publiques à construire pour rendre les choses plus claires.

Merci, comme çà on avancera un pas.

Bien, je reprend l'exemple original de la donnée à allouer :

Code:

typedef
struct
{
  int valeur;
}
Donnee;

Il nous faut donc un constructeur de pool :

Code:

Pool *pool_creer(size_t nb_donnees);

Il construit un pool de nb_donnees objets de type Donnee. Il n'est pas nécessaire que l'appelant sache de quoi est composé le type Pool.
Il faut aussi un destructeur :

Code:

void pool_detruire(Pool *p_pool);

Le but de cette fonction est clair, je pense.

On aborde maintenant ce qui est intéressant :

Code:

Donnee *pool_allouer_donnee(Pool *p_pool);

qui renvoie l'adresse d'un seul objet de type Donnee ou NULL si le pool n'a plus de place.

Code:

void pool_liberer_donnee(Pool *p_pool, Donnee *p_donnee);

permet au pool de considérer que cet objet n'est plus référencé par l'appelant. Il peut donc être "réalloué" lors d'un prochain appel de pool_allouer_donnee().

Comme vous le voyez, il n'y a rien de bien compliqué.

Pourquoi tu travailles uniquement avec des objets Donnees ?

nabiL a écrit:Pourquoi tu travailles uniquement avec des objets Donnees ?

Parce que le pool mémoire n'est fait que pour allouer des objets de même taille :

Wikipedia a écrit:Memory pools allow dynamic memory allocation comparable to malloc or C++'s operator new. As those implementations suffer from fragmentation because of variable block sizes, it can be impossible to use them in a real time system due to performance. A more efficient solution is preallocating a number of memory blocks with the same size called the memory pool.

Cela peut rendre la création et la destruction de listes chaînées, arbres, etc. plus rapides.

Fixer la taille de Donnees et varier le nombre de variables de type Donnees cause de la fragmentation aussi.

methodiX a écrit:Fixer la taille de Donnees et varier le nombre de variables de type Donnees cause de la fragmentation aussi.

Il ne peut pas y avoir fragmentation puisqu'on ne peut allouer qu'un élément à la fois.

Ou bien
je n'ai pas bien lu (donc mal compris) la notion de Pool
Ou bien
tu n'as pas bien expliqué cette notion (ça m'étonne)
Ou bien
il y a quelques choses qui cloche ...