This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Hi,

The 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. Because every thread should keep its own FIR state, I don't know what means to the thread safe requirement. Could you help me on the question?

Thanks

  • You'll have to provide more details on how the FIR 'state' information is accessed by the FIR code. If its all referenced through a single base address pointer then you can probably make the FIR thread safe simply by providing a unique 'state' buffer for each thread that invokes the FIR code.
    If the FIR code 'state' is a collection of ungrouped variables accessed by name (ie not fields within a struct), you'll have a lot more work ahead of you.

    Alan
  • Excuse me, I did not say the detail clearly. The filter coefficients are the same for the several threads, which have different data to be filtered. We know FIR internal states must be saved for the next time calling. The question is about what measure/structure must be used for these threads in real time, so that there is not racing or some resource contention happen. That is, to make this FIR can be called by several threads in a RTOS safely.

    Please reply to me if it is still not clear.

    Thanks, 

  • I'm still not sure I understand the problem.

    Are you saying that an FIR API is not re-rentrant and as such, how can re-entrancy be avoided when multiple threads (ie tasks) invoke this API at different times?

    If that is the question, then you could use a GateMutex instance to manage access to the FIR API.

    Each caller would then do something like this:

    GateMutex_enter(firGate);
    FIR_api();
    GateMutex_leave(firGate);

    Once a thread has successfully entered the gate, all other threads will block within GateMutex_enter() until the gate owner thread calls GateMutex_leave();

    Alan