2 ms·
Just a general question in regards to using memory allocators, in the consideration of a C only application. The problems I encounter with allocator and heap m
by longcommonname 7y ago
Just a general question in regards to using memory allocators, in the consideration of a C only application.
The problems I encounter with allocator and heap manager are almost never solved by these types of frameworks. These problems include:
1. Improper usage of the memory returned that contradict implementation.
2. Pool allocators that don't have separation between individual blocks (performance reasons).
3. Specifying the lifetime of the memory to a thread or until specific events happen.
4. Difficult to diagnose corruption, with any tool available.
Here's a specific scenario I deal with very often:
There are N persistent worker threads. These worker threads have their own pool of memory, and prior to getting work we know this pool is clean. After the work is finished and before more work is recieved the memory is cleaned. Any excess requested memory is returned to the global-pool, and any memory that is "unmanaged" is dealt with properly.
This means that people can do whatever heap management call you use (void * obtainMemory(size_t);) in the scope of business logic without having to worry about infrastructure concerns.
Having a faster malloc/calloc doesn't benefit me as much as making the usage of memory easier, and the understanding of what happens easier.