Texas Instruments TMS320 DSP User Manual download pdf (Page 18)

www.ti.com

2.2.4 Example

+ x

* x

n*1

)

n*2

Threads and Reentrancy

The definition of reentrant code often implies that the code does not retain "state" information. That is, if

you invoke the code with the same data at different times, by the same or other thread, it will yield the

same results. This is not always true, however. How can a function maintain state and still be reentrant?

Consider the rand() function. Perhaps a better example is a function with state that protects that state by

disabling scheduling around its critical sections. These examples illustrate some of the subtleties of

reentrant programming.

The property of being reentrant is a function of the threading model; after all, before you can determine

whether multiple threads can use a particular function, you must know what types of threads are possible

in a system. For example, if threads are not preemptive, a function may freely use global variables if it

uses them for scratch storage only; i.e., it does not assume these variables have any values upon entry to

the function. In a preemptive environment, however, use of these global variables must be protected by a

critical section or they must be part of the context of every thread that uses them.

Although there are exceptions, reentrancy usually requires that algorithms:

• only modify data on the stack or in an instance "object"

• treat global and static variables as read-only data

• never employ self modifying code

These rules can sometimes be relaxed by disabling all interrupts (and therefore, disabling all thread

scheduling) around the critical sections that violate the rules above. Since algorithms are not permitted to

directly manipulate the interrupt state of the processor, the allowed DSP/BIOS HWI module functions (or

equivalent implementations) must be called to create these critical sections.

Rule 2

All algorithms must be reentrant within a preemptive environment (including time-sliced preemption).

In the remainder of this section we consider several implementations of a simple algorithm, digital filtering

of an input speech data stream, and show how the algorithm can be made reentrant and maintain

acceptable levels of performance. It is important to note that, although these examples are written in C,

the principles and techniques apply equally well to assembly language implementations.

Speech signals are often passed through a pre-emphasis filter to flatten their spectrum prior to additional

processing. Pre-emphasis of a signal can be accomplished by applying the following difference equation

to the input data:

The following implementation is not reentrant because it references and updates the global variables z0

and z1. Even in a non-preemptive environment, this function is not reentrant; it is not possible to use this

function to operate on more than one data stream since it retains state for a particular data stream in two

fixed variables (z0 and z1).

int z0 = 0, z1 = 0; /* previous input values */

void PRE_filter(int input[], int length)

{

int I, tmp;

for (I = 0; I < length; I++) {

tmp = input[i] - z0 + (13 * z1 + 16) / 32;

z1 = z0;

z0 = input[i];

input[i] = tmp;

}

We can make this function reentrant by requiring the caller to supply previous values as arguments to the

function. This way, PRE_filter1 no longer references any global data and can be used, therefore, on any

number of distinct input data streams.

18 General Programming Guidelines SPRU352G – June 2005 – Revised February 2007

Submit Documentation Feedback

1 2 ... 13 14 15 16 17 18 19 20 21 22 23 ... 87 88

Comments to this Manuals

No comments

Texas Instruments TMS320 DSP User Manual Page 18

Comments to this Manuals