AN2345 Freescale Semiconductor / Motorola, AN2345 Datasheet - Page 4

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

Memory Manager Limitations
1.4 Mutual Exclusion
4
The best approach to ensuring reentrancy is to avoid the use of shared variables, but it is not always
possible to eliminate them in real-time systems. Usually, when shared variables are necessary, interrupts
are disabled until the shared variable is updated and then re-enabled. However, disabling interrupts
increases system latency, reducing the ability of the system to respond rapidly to external events. Another
approach to ensuring reentrancy is the use of a mutex, also referred to as a binary semaphore. Mutexes are
simple on-off state indicators whose processing is inherently atomic. Semaphores consume more
overhead than interrupt disabling, but they do not affect interrupt latencies.
Both of these reentrancy approaches can cause priority inversion. Priority inversion occurs when a
higher-priority task must wait on a lower-priority task to complete its use of a shared resource. In the
mutex approach, the task that owns a mutex retains control of its associated resource until the owner
determines that exclusive access is no longer needed. If another task with a higher priority attempts to
acquire the mutex, the kernel blocks the higher-priority task. In the interrupt disabling approach, a
higher-priority process is unable to interrupt a lower-priority process while interrupts are disabled,
forcing it to wait until the lower-priority process re-enables interrupts.
With the exception of two shared variables, all VSMM modules employ statically declared variables so
that each call has its own copy of these variables. To ensure reentrancy when either of the shared global
variables is updated, the VSMM can enable/disable interrupts or use a binary semaphore. The exact
method implemented depends on the critical method selected by the programmer. Refer to Section 3.6,
VSMM Critical Methods, on page 14 for details on the available VSMM critical methods. Since all
VSMM variables are either allocated to a specific instance or the enter/exit critical methods are used
when the shared variables are updated, all VSMM modules are reentrant.
While each process must have its own stack, it may or may not have its own heap, regardless of the heap
allocation scheme. If your allocation scheme has more than one heap, you must tune the size of a number
of heaps. A heap to be shared by many processes must be reentrant, which requires adding locks that may
slow down each allocation and deallocation. It may be necessary to allow one process to allocate a block
of memory that can be freed by another process, which is useful for passing inter-process messages.
When memory is passed between processes, it is important to ensure that the memory owner at each point
is well-defined. Two processes must not act as if they own a block of memory simultaneously. Otherwise,
there may be two calls to free the same memory block. Also, two processes must never attempt to manage
mutual exclusivity must be ensured. The following operation is atomic because nothing but a reset can
stop or interrupt the instruction:
move.1 d1, r0
Never assume that a compiler generates atomic code. For example, if we assume that the variable
gusiFooBar in the following instruction is global, this instruction may appear to be an atomic
instruction.
gusiFooBar += 1
However, the compiler may generate the following code, which is clearly not an atomic instruction and
therefore not reentrant:
move.w _gusiFooBar, d1
inc d1
move.w d1, _gusiFooBar
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com