What are Memory Byte Pools?
ThreadX memory byte pools are similar to a standard C heap. Unlike the standard C heap, it is possible to have multiple memory byte pools. In addition, threads can suspend on a pool until the requested memory is available.
Allocations from memory byte pools are similar to traditional malloc calls, which include the amount of memory desired (in bytes). Memory is allocated from the pool in a first-fit manner; i.e., the first free memory block that satisfies the request is used. Excess memory from this block is converted into a new block and placed back in the free memory list. This process is called fragmentation. Adjacent free memory blocks are merged together during a subsequent allocation search for a large enough free memory block. This process is called de-fragmentation.
Each memory byte pool is a public resource. ThreadX places no constraints on how pools are used, except that memory byte services cannot be called from ISRs.
How are Memory Byte Pools created?
Memory byte pools are created either during initialization or during run-time by application threads. There is no limit on the number of memory byte pools in an application.
What is the capacity of a Memory Byte Pool?
The number of allocatable bytes in a memory byte pool is slightly less than what was specified during creation. This is because management of the free memory area introduces some overhead. Each free memory block in the pool requires the equivalent of two C pointers of overhead. In addition, the pool is created with two blocks, a large free block and a small permanently allocated block at the end of the memory area. This allocated block is used to improve performance of the allocation algorithm. It eliminates the need to continuously check for the end of the pool area during merging.
During run-time, the amount of overhead in the pool typically increases. Allocations of an odd number of bytes are padded to ensure proper alignment of the next memory block. In addition, overhead increases as the pool becomes more fragmented.
Where can the memory for a Memory Byte Pool be located?
The memory area for a memory byte pool is specified during creation. Like other memory areas in ThreadX, it can be located anywhere in the target’s address space.
This is an important feature because of the considerable flexibility it provides. For example, if the target hardware has a high-speed memory area and a low-speed memory area, the user can manage memory allocation for both areas by creating a pool in each of them.
What happens if a thread tries to allocate memory from a byte pool that has not enough available?
Application threads can suspend while waiting for memory bytes from a pool. When sufficient contiguous memory becomes available, the suspended threads are given their requested memory and the threads are resumed.
If multiple threads are suspended on the same memory byte pool, they are given memory (resumed) in the order they were suspended (FIFO).
However, priority resumption is also possible if the application calls tx_byte_pool_prioritize prior to the byte release call that lifts thread suspension. The byte pool prioritize service places the highest priority thread at the front of the suspension list, while leaving all other suspended threads in the same FIFO order.
Where can I find more information?
You can find more information on the ThreadX user manual, available on the Synergy Gallery in the X-Ware zip file here: https://synergygallery.renesas.com/ssp/support#read
©1997-2015 by Express Logic, Inc. All rights reserved. This document and the associated ThreadX software are the sole property of Express Logic, Inc. Each contains proprietary information of Express Logic, Inc.