On Thu, 04 Jun 2015 05:51:46 -0700, Robert Willy wrote:
> 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?
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
Reply by Nobody●June 4, 20152015-06-04
On Thu, 04 Jun 2015 05:51:46 -0700, Robert Willy wrote:
> 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.
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.
Reply by Rob Gaddi●June 4, 20152015-06-04
On Thu, 04 Jun 2015 05:51:46 -0700, Robert Willy wrote:
> 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
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.
Reply by Don Y●June 4, 20152015-06-04
On 6/4/2015 5:51 AM, Robert Willy wrote:
> 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?
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.]
Reply by Robert Willy●June 4, 20152015-06-04
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