Hello,
My FIR design is good for a single thread. Now, I am required to make several threads using the same FIR under TI-RTOS. The manager says the FIR should be a generic one. And every thread should keep its own FIR states for the next time call. I don't know what means to the thread safe requirement.
Could you help me on the question?
Thanks
Any structures/data that your code requires to implement the functionality has to be protected from possibly competing uses (e.g., two or more instances of your code running at "the same time" -- or, at least the illusion of concurrency).
Frankly, I can't see how that would be the case: keep the data for each instance separate and that does the trick.
So, instead of "hard coding" all of the variables that you use, pass (a) reference(s) (pointer) to them to your routine; let it access the variables through that pointer(s). As such, each instance of your routine (function) will have its own pointer (provided to it when the function instance is invoked) and, consequently, it's own independent set of variables.
As you'll tend to have a number of variables (filter coefficients, state, etc.) it's easiest to just wrap a *set* of variables for one filter in a structure and pass a pointer to that structure to your routine (function).
[You'll have to consider how you initialize these independent structures for each filter, etc.]
Go compare strtok to strtok_r. The reentrant verion (which is what you're concerned about) takes a third argument, a pointer to somewhere that it can store its internal state between calls. For strtok, that internal state is just a char*, so the saveptr is a char**.
For your FIR filter, your internal state (probably just the input data) will be some big complicated thing, a struct firstate_t. That means you want your fir filter to provide functions like the following.
struct firstate_t *fir_init(struct firstate_t *state); int16_t fir_data(int16_t newdata, struct firstate_t *state);
-- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Don't use global or "static" variables (with the possible exception of data such as tables which are initialised prior to first use and not modified thereafter).
Any state which needs to be preserved from one call to the next should be accessed via a pointer passed in by the caller.
What everyone has said so far. The real danger is modifying some common bit of memory that you expect is exclusive to one version of the function, not all.
Based on your question, I think you need to get yourself a book on embedded programming and study it. "The Art of Embedded Programming" by Ganssle comes highly recommended. I haven't read the book, but I've read a lot of Jack's other work, and have talked to him from time to time. He's bedrock-sensible, a good author, and he knows embedded system programming inside and out.
-- www.wescottdesign.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.