In the last several posts, we have been exploring common issues that developers encounter when designing an embedded system with an RTOS. So far, we have discussed priority inversion and dead locks which are potentially the most dangerous and elusive issues that a developer will encounter. In most instances, all the issues that a developer can encounter are self-inflicted through design oversights or improper implementation and can be avoided through design reviews and using RTOS mechanisms designed to minimize such issues. In this post, we will examine thread starvation.


Thread starvation occurs when a thread is ready to run but is indefinitely delayed from running due to the required resources being unavailable or other higher priority threads always preempting it. The simplest case for thread starvation occurs when there is a low priority background thread that is continuously preempted by higher priority threads and is never able to run to completion within its deadline. The starvation is caused by there not being enough processing bandwidth to handle all the tasks which can be caused by:

  • Improper priority selection
  • Periods where there are many external events occurring in the system
  • The software processing utilization is greater than 90%


Thread starvation symptoms can be obvious or they can be subtle. An obvious case would be that a user is trying to use the system and discovers that the system response is sluggish and slow. In other cases, a user may not even notice that the system is misbehaving but behind the scenes, data isn’t quite being updated in real-time or is stale.


Thread starvation also doesn’t need to be caused by a thread always being preempted by another thread. A thread can be starved if another thread is holding on to a mutex or semaphore and not releasing it. If another thread requires access to the shared system resource it will starve. The most extreme starvation case can result in deadlock which we discussed in the last post.


Developers need to make sure that they are not only aware that thread starvation can occur in their system but they also need to understand how to prevent it. There are several techniques that developers can use to prevent thread starvation. First, developers need to analyze their threads by first performing a rate monotonic analysis (RMA) to determine the initial priorities for their threads (See Managing Thread Priorities: Click Here). Once this is done, developers need to follow-up and verify in their system that their initial assumptions about execution times and periods still hold and that interactions with other threads and events don’t require the threads to be reprioritized.


Next, developers should avoid using polling or any executable code that injects delays in code execution that does not yield the CPU. Threads that are polling or delaying without yielding the CPU are eating up precious clock cycles that could be used by other threads that are being starved. Finally, developers could also use the ThreadX® preemption threshold feature. Preemption threshold allows a developer to set the minimum priority a thread must have before a thread is preempted. This feature can give threads that would otherwise be preempted and possibly starved more opportunity to use the CPU. (See Transitioning to ThreadX: Avoiding Priority Inversion Issues, Click Here)


One key element that readers will notice with RTOS application related issues is that most issues can be eliminated by properly analyzing their system and properly setting their thread priorities. In the next post, we will examine the last common RTOS related issue which is known as thread jitter.



Until next time,


Live long and profit!





Hot Tip of the Week

The Synergy Tools ISDE is constantly being improved to make development easier and more productive. For example, the most recent release of e2 studio for the Synergy Platform includes a new stack export import wizard. This new function makes it easy to move module stacks from one project to another (if they share the same minor version of SSP- e.g. SSP v1.2.x). You can dig into the details of this powerful new feature by reading the Knowledge Base article available here.


As always, the most recent versions of e2 studio and SSP are available from the Synergy Gallery here. Make sure you update to SSP 1.2.1 and e2 studio to access all the other new features too!