AllocPooled
-
J’ai vu que cela trainait dans un proto et que quelqu’un l’utilisait dans son programme… Corto pour ne pas le citer, au sujet de SQlite…
Qu’est-ce qu’exactement ce AllocPooled ?
Quelles différences (avantages) avec Allocmem ?
Quelqu’un peu prendre quelques minutes pour m’filer quelques infos ?
AllocPooled() c’est comme AllocMem() sauf qu’au lieu d’allouer de la mémoire depuis la table globale, AllocPooled() alloue depuis une piscine.
Tu vas me dire : « m’enfin c’est quoi une piscine ? ». Une piscine (ou pool en anglais) c’est un bébé gestionnaire de mémoire. Tu peux allouer plein de morceau depuis la piscine, elle grandit et rétrécie selon les usages. Mais le mieux c’est qu’au lieu de détruire tous les petits blocs en te prennant la tête, tu peux supprimer toutes les allocations faites par la piscine d’un seul coup en détruisant la piscine ! C’est-y pas merveilleux ?
Les piscines ont donc deux intérêts : la facilité d’utilisation (réduisant les risques de fuites de mémoire) et la faible fragmentation (de gros bloc sont alloués pour y placer plein de plus petits).
Le système mémoire de Feelin est basé sur ce concept… avec des améliorations biensûr.
amifred : Je crois que Gofromiel a tout dit. AllocPooled permet d’allouer une zone mémoire au sein d’un pool (un bloc mémoire unique) et si ce dernier est plein, il est automatiquement étendu.
L’exemple en question repose sur les listes de MUI dont les méthodes d’ajout et de suppression d’entrées reçoivent en paramètre un Pool mémoire.
Merci pour vos réponses, les gars
Donc avant d’mettre mon maillot, j’aimerai éclaircir quelques points…
Avant d’utiliser AllocPooled je dois remplir la piscine,
une fois pour toute au début de mon programme et si jamais la piscine s’avérait trop petite, pour éviter les bosses lors de mes plongeons, elle s’agrandirait AUTOmatiquement, sans une ligne de code supplémentaire ?
J’ai bon ?
En fait, tu n’as pas besoin de ‘remplir’ la piscine. Tout ce que tu as à faire c’est l’installer sur un coin d’herbe. La piscine se remplie par de grosses flaques (puddles) où sont allouées de plus petites unités (les allocations mémoire).
C’est pour cela que les piscines fragmentent moins la mémoire. Au lieu d’avoir plein de petites allocations qui courrent partout, on réserve de gros (pas si gros quand même) bloc dans lesquel on place les petits. C’est pour cela que les piscines grandissent et rétrécissent selon la demande: s’il n’y a plus de petits blocs dans le puddle, le puddle est détruit, et au contraire, s’il n’y a plus d’espaces libres dans aucun puddle pour y placer une petite allocation, un nouveau puddle est crée.
Pffffft ! Encore trop froide pour que j’me jette…
Pourais-tu avoir la gentillesse de me mettre un exemple:
initialisation/utilisation/destruction…
Surtout les paramètres de l’init… Car j’ai bien regardé sur ton site (F_AllocPooledA…), mais l’anglais et moi: c’est pas ça… (un rêve: Feelin en français… )
Merci pour les explications.
F_AllocPooledA() c’est pas une fonction qui existe Pour un example instructif qui en plus met le système mémoire de EXEC et celui de Feelin en compétition, télécharge le package « base » sur la page download. Ensuite regarde le fichier « /demos/memorytest.c ».
Si tu as des questions après ça, je suis à ta disposition.
Ton clavier a fourché de beaucoup
Sinon les devs, y a un truc que vous dites pas c’est, si moi pas tromper, qu’il faut préférer AllocPool aux autres fonctions d’allocation mémoire.
Bon j’ai lu memorytest.c…
ça a l’air simple comme ça, mais j’ai quelques interrogations tout d’même sur le pourquoi du comment…
On y mesure le temps d’allocation de blocs mémoire (à partir d’un pool), mais comme l’exé plante chez moi…
Je suppose que le temps en passant par Feelin est plus court et, comme tu dis avoir protégé le truc (le roi de la sémaphore, non ?), plus sûr…
Qu’est-ce qu’exactement un puddle et un thresh dans:
newPool = CreatePool( memFlags, puddleSize, threshSize ) ?
Je propose:
pour puddle = la taille de la piscine exprimée en nb x taille d’un élément
pour thresh = la taille d’un élément (le truc qui sert dans AllocMem ?)
Je n’te dis pas le résultat de la tradoc de ces mots avec Babel…
et si j’alloue un truc plus grand que thresh avec un AllocPooled ?
De plus j’ai vu AllocVec… qu veut dire précisément:
« …but tracks the size of the location. » ?
D’avance merci
‘lut elwood
Tu disais: « …il faut préférer AllocPool aux autres fonctions d’allocation mémoire. »
Tu peux donner quelques raisons…
Je ne voudrais pas allouer un bloc mémoire qui ne serait pas utilisé (taille du pool)…
Voilà ce que j’en comprends à l’heure actuelle et ce que je voudrais faire:
j’alloue un pool (CreatePool) avec un puddle = thresh = taille d’UN élement… (taille minimale)
Je fais des AllocPooled/FreePooled pour chaque élement dont j’ai besoin… ( si j’ai bien compris mon pool augmentera automatiquement ou se réduira automatiquement )
Je garde la possibilité de détruire tout le Pool d’un coup ou des places d’éléments à volonté…
La seule différence avec AllocMem, c’est le vidage complet de la piscine… non ?
Dans les deux (AllocMem ou AllocPooled), il faut tester si l’attribution de la mémoire a été possible…
J’espère que je n’suis pas trop loin de la réalité…
Ben en fait je me trompe. J’ai confondu avec AllocVec et AllocMem, bref je suis hors-sujet donc je me tais et je laisse parler les pros.
A l’utilisation, une fois le pool créé avec le puddle et tresh judicieusement choisis, c’est comme un allocmem, il faut tester le retour bien sûr.
Si tu as plusieurs tâches, il faut utiliser un sémaphore pour arbitrer les accès.
Un avantage est que tu peux détruire complètement le pool au lieu de libérer chaque allocation individuellement, ce qui fait gagner un peu de temps.
L’intérêt des pools est essentiellement de limiter la fragmentation comme dit x fois plus haut.
Sous morphos, il y a eu quelques extensions pratiques comme un AllocVecPooled, ou encore un flag MEMF_SEM_PROTECTED qui arbitre les accès concurrents.
Elwood,
sous OS4, vous êtes censés avoir implémenté un système de gestion mémoire global bien plus performant que les pools au fait. Je suppose donc qu’il vaut mieux recommander AllocMem que AllocPooled pour une performance maximale à l’avenir non (ou du moins ça ne devrait pas faire de différence) ?
Je suppose que le temps en passant par Feelin est plus court et, comme tu dis avoir protégé le truc (le roi de la sémaphore, non ?), plus sûr…
@amifred: Oui, et de loin !!En plus, quelque soit la piscine depuis laquelle tu as alloué de la mémoire et quelque soit la taille de l’allocation, il n’existe qu’une seule fonction pour libérer le bloc: F_Dispose(), qui a seulement besoin de l’adresse du bloc, aucontraire de FreePooled() qui a en plus besoin de la piscine ainsi que de la taille de l’allocation.
De plus, le système mémoire de Feelin est très sûr. En effet, il est IMPOSSIBLE d’effacer un bloc mémoire qui n’éxiste pas. Essaie donc de faire un « FreePooled(piscie, (APTR) 0xABBA, 128); » pour comparer
En plus (je fais ma pub) les développeurs sont comblés de bonheur avec le support du mungwall, le marquage (la classe et la méthode d’où l’allocation a été faite est inscrite dans le bloc mémoire) et divers pattern de remplissage mémoire: 0xABADBEEF pour de la nouvelle mémoire non mise à zéro (lorsque la piscine est crée sans MEMF_CLEAR), 0xDEADBEEF lorsqu’un bout de mémoire est libéré…
En plus (encore) chaque piscine embarque sont propre sémaphore, pas besoin de se casser les fesses comme avec le système d’EXEC. Tu bloques la piscine avec F_OPool(), tu la partage avec F_SPool() et tu la libère avec F_RPool().
C’est tellement bien tout ça, que ça me donne envie de sauter par la fenêtre rien que de penser à devoir utiliser le système d’EXEC !
Une question tout de même: tu me dis que la démo « MemoryTest » plante. Est-ce que tu reçois un message d’erreur de Feelin ? Personnellement, sur WinUAE, lorsqu’EXEC ne peut plus allouer de mémoire, le système plante avec un jolie bandeau « OUT OF MEMORY ». C’est terrible, mais c’est comme ça. Est-ce que c’est ça ?? Sinon, tu peux désactiver le test sur EXEC ou Feelin, pour voir…
Ca m’intrigue !! C’est quoi ta congif ??
Fab1, j’avais saisi le principe, mais tu disais:
> A l’utilisation, une fois le pool créé avec un puddle et tresh judicieusement choisis, c’est comme un…
Justement, comment choisir judicieusement le puddle et le thresh ?
Que représentent exactement ces deux bidules ?
Cette toute cette finesse du langage qui va me permettre de l’utiliser et de choisir…
Et pour AllocVec ? … tracks the size of the allocation…
Qu’est-ce que ça veut dire ?
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › AllocPooled