Memory pool (fixed-size block allocator) in Embedded C - Deep Dive

Overview - Memory pool (fixed-size block allocator)

What is it?

A memory pool is a way to manage memory by dividing a big chunk into many small, fixed-size blocks. Instead of asking the system for memory every time, the program grabs a block from this pool. This makes memory allocation faster and more predictable, especially in embedded systems where resources are limited. It helps avoid fragmentation and keeps memory use efficient.

Why it matters

Without memory pools, programs would request and free memory directly from the system, which can be slow and cause memory to become fragmented over time. This fragmentation wastes memory and can cause programs to crash or slow down. Memory pools solve this by reusing fixed-size blocks, making memory management faster and more reliable, which is critical in devices like sensors, controllers, or small gadgets.

Where it fits

Before learning memory pools, you should understand basic memory allocation and pointers in C. After mastering memory pools, you can explore dynamic memory management techniques, custom allocators, and real-time operating system (RTOS) memory handling.

Mental Model

Core Idea

A memory pool is like a toolbox filled with identical compartments, each holding one fixed-size block of memory ready to be used or returned instantly.

Think of it like...

Imagine a box of identical ice cube trays. Instead of making new ice cubes every time, you just take one from the tray when you need it and put it back when done. This saves time and keeps things organized.

┌─────────────────────────────┐
│        Memory Pool          │
├─────────────┬───────────────┤
│ Block 1     │ Free or Used  │
│ Block 2     │ Free or Used  │
│ Block 3     │ Free or Used  │
│ ...         │ ...           │
│ Block N     │ Free or Used  │
└─────────────┴───────────────┘

Allocation: Take a free block → Mark as used
Deallocation: Mark block as free → Return to pool

Build-Up - 7 Steps

1

Foundation

Understanding fixed-size memory blocks

Concept: Memory can be divided into small, equal parts called fixed-size blocks.

In embedded C, memory is a continuous area. We split this area into many blocks of the same size. Each block can hold one data item or structure. This fixed size means every block is interchangeable and easy to manage.

Result

You get a clear layout of memory divided into equal parts, ready for allocation.

Knowing that blocks are fixed size simplifies management because you don't need to track different sizes or merge blocks.

2

Foundation

Basic pool initialization and structure

Concept: A memory pool needs a structure to hold the blocks and track which are free or used.

We create an array or buffer in C to hold all blocks. Then, we keep a list or bitmap to mark blocks as free or used. Initialization sets all blocks as free, ready to be allocated.

Result

A ready-to-use memory pool with all blocks free.

Setting up a clear tracking system is key to fast allocation and deallocation.

3

Intermediate

Allocating blocks from the pool

🤔Before reading on: do you think allocation searches the whole pool or uses a faster method? Commit to your answer.

Concept: Allocation finds a free block quickly and marks it as used.

When a program requests memory, the allocator looks for a free block. It can use a free list (a linked list of free blocks) to get the first available block instantly. Then it marks that block as used and returns its address.

Result

The program gets a pointer to a free block without scanning the entire pool.

Using a free list avoids slow searches and keeps allocation time constant.

4

Intermediate

Deallocating blocks back to the pool

🤔Before reading on: do you think deallocation clears the block data or just marks it free? Commit to your answer.

Concept: Deallocation returns a block to the pool by marking it free and adding it back to the free list.

When the program finishes using a block, it calls deallocation. The allocator marks the block as free and links it back into the free list. This makes the block available for future allocations.

Result

The block is recycled efficiently without complex memory operations.

Quickly returning blocks prevents memory leaks and keeps the pool healthy.

5

Intermediate

Handling pool exhaustion and errors

🤔Before reading on: do you think allocation fails silently or returns a special value when no blocks are free? Commit to your answer.

Concept: The allocator must handle cases when no free blocks remain and signal errors properly.

If all blocks are used, allocation returns NULL or an error code. The program must check this to avoid crashes. Some pools can grow or block until memory frees, but fixed pools usually just fail fast.

Result

Programs can detect and handle out-of-memory situations gracefully.

Proper error handling prevents crashes and undefined behavior in embedded systems.

6

Advanced

Optimizing with alignment and block size choices

🤔Before reading on: do you think block size affects speed or memory waste more? Commit to your answer.

Concept: Choosing block size and alignment affects performance and memory efficiency.

Blocks should be aligned to CPU word size for speed. Larger blocks waste memory but reduce fragmentation. Smaller blocks save memory but increase overhead. Balancing these depends on the application’s needs.

Result

A memory pool tuned for the target hardware and workload.

Understanding hardware alignment and block size tradeoffs leads to better embedded system performance.

7

Expert

Advanced: Using memory pools in real-time systems

🤔Before reading on: do you think memory pools guarantee constant-time allocation? Commit to your answer.

Concept: Memory pools provide predictable, constant-time allocation critical for real-time systems.

Real-time systems need guaranteed timing. Memory pools avoid unpredictable delays from system allocators. Using fixed-size blocks and free lists, allocation and deallocation take constant time, ensuring system responsiveness.

Result

Real-time applications can meet strict timing requirements using memory pools.

Knowing that memory pools enable deterministic timing is key for embedded real-time programming.

Under the Hood

Internally, the memory pool holds a large buffer split into fixed-size blocks. A free list links all free blocks using pointers stored inside the blocks themselves. Allocation removes the first block from the free list, and deallocation adds it back. This pointer manipulation is done without extra memory overhead. The system avoids fragmentation because blocks are uniform and never merged or split.

Why designed this way?

Memory pools were designed for embedded systems where memory is scarce and allocation speed is critical. Traditional allocators cause fragmentation and unpredictable delays. Fixed-size blocks and free lists simplify management and guarantee constant-time operations, which is essential for real-time and resource-constrained environments.

┌───────────────┐
│ Memory Buffer │
├─────┬─────┬───┤
│Blk1 │Blk2 │...│
└─────┴─────┴───┘

Free List:
Blk1 → Blk3 → Blk7 → NULL

Allocation:
Take Blk1 from free list

Deallocation:
Add block back to free list head

Myth Busters - 4 Common Misconceptions

Quick: Does a memory pool automatically resize when full? Commit yes or no.

Common Belief: Memory pools grow automatically when they run out of blocks.

Reality: Fixed-size memory pools do not grow; they have a fixed number of blocks. If full, allocation fails or returns NULL.

Why it matters: Assuming automatic growth can cause crashes or memory corruption when the pool is exhausted.

Quick: Does deallocating a block clear its data automatically? Commit yes or no.

Common Belief: Deallocating a block erases its contents to prevent data leaks.

Reality: Deallocation only marks the block as free; it does not clear data. The next allocation may see leftover data unless explicitly cleared.

Why it matters: Not clearing sensitive data can cause security risks or bugs if reused blocks contain stale information.

Quick: Is memory fragmentation a problem with fixed-size block allocators? Commit yes or no.

Common Belief: Memory pools eliminate all fragmentation problems.

Reality: Fixed-size pools prevent external fragmentation but can suffer internal fragmentation if block size is larger than needed.

Why it matters: Ignoring internal fragmentation can waste memory and reduce efficiency.

Quick: Can you safely allocate and free blocks from multiple threads without locks? Commit yes or no.

Common Belief: Memory pools are always thread-safe without extra synchronization.

Reality: Most memory pools are not thread-safe by default; concurrent access requires locks or atomic operations.

Why it matters: Ignoring thread safety can cause data corruption and crashes in multi-threaded programs.

Expert Zone

1

Some memory pools embed the free list pointers inside the free blocks themselves to avoid extra memory overhead.

2

Choosing block size to match the most common allocation size reduces internal fragmentation and improves cache performance.

3

In some designs, pools can be layered or combined with other allocators to handle variable-sized allocations efficiently.

When NOT to use

Memory pools are not suitable when allocations vary widely in size or when memory usage is highly dynamic. In such cases, general-purpose allocators or slab allocators are better. Also, if thread safety is required, specialized concurrent allocators or locks must be used.

Production Patterns

In embedded firmware, memory pools are used for managing network buffers, task stacks, or sensor data buffers. Real-time operating systems often provide fixed-size pools for deterministic memory management. Pools are also common in game engines for fast object reuse.

Connections

Slab allocator

Builds-on

Memory pools are a simpler form of slab allocators, which manage caches of objects with fixed sizes but add metadata and object lifecycle management.

Real-time operating systems (RTOS)

Supports

Memory pools provide the predictable timing guarantees that RTOS require for safe and reliable task scheduling.

Inventory management

Analogous process

Managing a memory pool is like managing inventory of identical items in a warehouse, where quick allocation and return of items keeps operations smooth.

Common Pitfalls

#1 Not checking if allocation succeeded before using the block.

Wrong approach:

char* ptr = mempool_alloc(&pool);
strcpy(ptr, "data"); // no NULL check

Correct approach:

char* ptr = mempool_alloc(&pool);
if (ptr != NULL) {
strcpy(ptr, "data");
} else {
// handle allocation failure
}

Root cause:

Assuming allocation always succeeds leads to dereferencing NULL pointers and crashes.

#2 Freeing a block that was never allocated or already freed.

Wrong approach:

mempool_free(&pool, invalid_ptr); // pointer not from pool or double free

Correct approach:

// Only free pointers returned by mempool_alloc and not yet freed
mempool_free(&pool, valid_ptr);

Root cause:

Misunderstanding ownership and lifecycle of blocks causes memory corruption.

#3 Using blocks of wrong size or misaligned pointers.

Wrong approach:

char* ptr = mempool_alloc(&pool);
int* int_ptr = (int*)ptr;
*int_ptr = 42; // if block not aligned properly

Correct approach:

// Ensure block size and alignment match data type
int* int_ptr = (int*)mempool_alloc(&pool);

Root cause:

Ignoring alignment requirements causes undefined behavior and crashes.

Key Takeaways

Memory pools divide a fixed memory area into equal blocks for fast, predictable allocation and deallocation.

They prevent fragmentation and speed up memory operations, which is vital in embedded and real-time systems.

Allocation and deallocation use a free list to keep operations constant time and efficient.

Proper error handling and understanding of pool limits prevent crashes and bugs.

Choosing the right block size and alignment balances memory use and performance.