free - but keep - memory pool

[Honitos]

I created a memory pool using CreatePool().


I need to free the pool but keep it, as maybe there will be allocated memory in the pool again.


Using DeletePool() will free the memory but destroy the pool as well.
Is there any way to free the pool, but keep it?

[Samurai_Crow]

FreePooled is what you are looking for.

[Honitos]

Unfortunately not: FreePooled() needs address an size of *each* memory block that belongs to the pool, and I dont store these data.

If I have to manage a memory list to keep track of all the memory snippets I allocated, I just could use good old AllocMem()/FreeMem() instead of the pooling.

[Samurai_Crow]

In that case, system pools are not what you are looking for. AllocMem() and custom code, as you proposed, are the solution.

[Olaf Barthel]

Originally Posted by Honitos

I created a memory pool using CreatePool().


I need to free the pool but keep it, as maybe there will be allocated memory in the pool again.


Using DeletePool() will free the memory but destroy the pool as well.
Is there any way to free the pool, but keep it?

Could be that memory pools are not the exact solution you were looking for. But maybe they fit better than you expect them to if you reconsider what they can do for you, given their strengths.

The memory pools are helpful if you are going to make many, many small allocations over the lifetime of your application. These small allocations will invariably contribute negatively to general memory fragmentation issues (the more fragments, and the more smaller fragments, the slower allocating and freeing memory will become). If you can stick them all into a memory pool instead, the problem practically goes away because any fragmentation, if at all, will only happen in the pool.

Memory pools are also helpful if you need to make sure that every single memory allocation made is freed before your application eventually exits. The pools keep track, generally, of all the allocations made. No need to keep track of them individually all by yourself.

Memory pools can be used to group together related allocations which you will be releasing together anyway in your application. Instead of allocating these one at a time, you create a pool for them, allocate the memory you need, make use of it, then free the pool.

Finally, memory pools are a bit more efficient than making individual allocations through AllocMem/FreeMem/AllocVec/FreeVec. Each time you call one of these, the operating system briefly needs to stop multitasking until the function has completed its task. This kind of thing happens much more rarely if you call AllocPooled/FreePooled because a pool allocates the requested memory from one of the puddles which make up the pool. No need to call Forbid/Permit as part of the job all the time.

If you can make them work for you, memory pools can make memory management much, much simpler. You certainly can make use of more than one pool in your application over time, disposing and re-creating them as necessary.

[meynaf]

A possibility is to call CreatePool right after DeletePool, to recreate the deleted pool.

[Honitos]

@meynaf: That is my workaround since yesterday!

@Olaf Barthel: Yes, for these reasons I want to use pools. While digging in the source code of a lib that handles linked lists in AmiBlitz, I found out that someone started to implement dynamic lists that allocate memory only if a list element is added. This way you can dim a list this way:

Dim mylist.TagItem(0)

This way that list is initiated and a pool is been created: the coder already used pooling for that purpose which seems to be the right solution.

But the feature is not complete: every time a new list entry is created, the memory will be allocated from the pool, but the memory is never been freed, even after exiting the program.

My problem is: the initiation of the dynamic array as well as the pool creation is done in another blitzlib (arrayslib). The list handling and memory allocation itself is done in linkedlistlib. To be able to clear a list at runtime, I have to free the pool in that lib.

I already added a routine to delete and recreate a pool, if a list is been cleared. That works as expected but is not the best solution as I delete a pool that has been created from another lib.

[Olaf Barthel]

Originally Posted by Honitos

I already added a routine to delete and recreate a pool, if a list is been cleared. That works as expected but is not the best solution as I delete a pool that has been created from another lib.

So what you need is really a bug fix, isn't it?