What measures should I take to make this multi-thread safe?

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).

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);

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.