• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 1007 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TI RTOS priority inversion question

Fred Assadi
Intellectual 330 points

Hi,

<I am using the CCS 6.1 & TI RTOS for TIVA 2.14.00.10 on a TMC129xnczad SDK, and have no previous experience with the TI RTOS kernel.>

I have created a low priority (3) alarm task that processes system alarms. The alarm task is created with a mailbox of size of 10.It is expected that the system would not receive more than 2- 3 alarms during an "alarm storm".

One of the functions of the alarm task is to screen out duplicate alarms and discard them.

During testing, I created a higher priority (4) test task to send a bunch of duplicate alarms to the alarm task and verify its operation. All worked well until I posted the 12th alarm (Not sure why 12 and not 11) At that point the higher priority task stopped, pending for the lower priority task to have available system resources (mail box posts) to process the next alarm. While this behavior is expected, It occurred to me that any low priority task ( > 3 in my example) that fails and attempts to post lots of events, is going to block not just itself but also all higher priority tasks (say 15)  that may only have only one event to post. This reminds me of a "Denial Of Service" type attacks that have become prevalent on the internet.

I suppose that I can use multiple mail boxes for various tasks, or promote the checking for the duplicate alarms to the priority of the caller, but there has to be a better way of handling this type of rather common problem, so failure of one task does not take the whole system down.

Appreciate any suggestions,

Fred

  • 0
    TI__Genius 12865 points
    Hi Fred,

    I think you have mentioned the main solutions:

    - use different mailboxes for high priority vs low priority messages
    - raise the priority of the alarm processing task to prevent priority inversion

    If you suspect there is a chance that a lower priority (>3) task may fail and start flooding the system with messages, you can also maybe throttle it with a delay between messages it sends. This would give the rest of the system a chance to handle the high priority messages in the event the lower priority task goes "Mailbox_post happy". Of course such a delay would have to be carefully chosen to meet the latency requirements in responding to the lower priority messages as well.

    Yet another approach would be to make the lower priority task monitor the amount of time between alarms, and detect any suspicious activity and avoid doing a Mailbox_post as a consequence.

    Best regards,
    Vincent