AN2345 Freescale Semiconductor / Motorola, AN2345 Datasheet - Page 5

• Manufacturer Part Number: AN2345
• Description: Real-Time Memory Manager for StarCore DSPs
• Manufacturer: Freescale Semiconductor / Motorola

Freescale Semiconductor, Inc.
Memory Manager Limitations
the same heap simultaneously. For example, if one process attempts to allocate a block of memory and
fails to update the global free list pointer before it is preempted by a process with a higher priority, the
global free pointer can easily become corrupt.
All memory managers have sections of code deemed critical, such as the update of the global free list
pointer or the memory control block (MCB). Critical sections are the sections of a program that are
vulnerable to undesirable interruption or corruption. To provide exclusivity to these sections, a locking
mechanism is needed. Mutual exclusion is the implementation of a locking mechanism to ensure that
only one process has access to a resource or critical section of code at any given time. The VSMM
guarantees mutual exclusion through the use of “critical methods,” which are associated with routines
used prior to entry into and exit from critical sections. Before entry into a critical section, these routines
can perform the following tasks:
• Save the current interrupt state and disable interrupts
• Change the interrupt priority level so that only processes with a specific priority are allowed to
generate and service interrupts
• Use a binary semaphore to ensure mutual exclusivity.
Upon exit from a from a critical section, these critical methods can re-enable interrupts or restore
interrupts to their previous saved state or unlock a binary semaphore.
As a result of ensuring mutual exclusivity of critical sections, priority inversion is possible. However,
since all VSMM critical sections are extremely short and execute rapidly, this issue is minor but one that
deserves attention.
1.5 Memory Leaks
Many objects, structures, or buffers exist for a period of time that does not match the invocation of any
one function. This is particularly true in event-driven programs, such as many embedded real-time
systems. One event may cause an item to be created, and that item remains in use until some other event
leads to its elimination. At a certain point in the code, you may be uncertain whether a particular block is
still needed. If you free this block of memory but continue to access it, say, via a second pointer to the
same memory, the program may function well until that particular block of memory is reallocated to
another part of the program. Then, two different parts of the program proceed to write over the shared
space. If you decide not to free the memory because it may still be in use, then there may not be another
opportunity to free it if all pointers to the block are out of scope or reassigned to point elsewhere. In this
case, the program logic is not affected, but if the piece of code that leaks memory is regularly visited, the
leak tends towards infinity as the execution time of the program increases.
Ultimately, the amount of physical memory determines how long a program can execute. On many
desktop applications, a small leak may be acceptable. For example, a compiler that leaks 100 bytes for
every 1,000 lines compiled can still successfully compile a 100,000 line file on a modern PC, since all
allocated memory is recovered on exit of the program. However, in many embedded systems in which
minimal memory is available, no upper limit on the life of the program is acceptable. Any memory leak is
an error to be rectified by correcting the logic of the application program. By monitoring the size of each
heap and confirming that the number of blocks in use ceases to grow after extended use, the programmer
can be confident that leaks are eliminated. While it is wise to size the heaps larger than the worst case
seen in testing, too much padding leads to wasted memory.
The VSMM is verified to contain zero memory leaks. However, this does not guarantee that your system
or application will not leak. The VSMM provides a query routine that reports the current statistics of a
heap. This routine can be very useful in determining whether your system contains any memory leaks.
For example, if you perform a query on each heap before the system exits, if any heap statistics indicate
memory blocks still in use, there are memory leaks within the system.
5
For More Information On This Product,
Go to: www.freescale.com