Transitioning to ThreadX: Managing Thread Priorities

So far in this series we have been discussing how to create threads and properly size their stack so that developers are able to efficiently use their RAM while not risking a stack overflow. There is far more to thread management than simply getting the stack size correct. Developers need to understand how to make sure that all their threads will be able to meet their real-time deadlines. In order to accomplish this, developers need to employ some best practices and a commonly used scheduling technique known as rate monotonic analysis (RMA) which is sometimes referred to as rate monotonic scheduling (RMS).

Before diving into the details on how to perform a RMA, it is important for developers to realize that RMA is a starting point for ensuring that all tasks will meet their deadlines. RMS is a great theoretical starting point for developers but RMS assumes that

• The threads in the application are periodic
• Threads are running independently and are not synchronized through semaphores, mutexes, message queues or event flags
• Data is not exchanged between threads
• The RTOS is configured for preemptive scheduling and not round robin
• The thread priorities are static and not changing during run-time

Even with these assumptions, performing an RMA will provide a developer with a foundation from which they can determine whether their task priorities are appropriate and determining if their design is moving in the right direction. One result from RMA is that the theoretical limit for CPU load to meet real-time deadlines with in infinite number of threads is 69.3%. means that any analysis that shows a CPU usage greater than or equal to 70% for periodic threads is probably not going to work in real life without threads missing their deadlines! The remaining 30% is used for non-periodic threads and interrupts.

There are several steps that developers can follow to perform an RMA analysis on their own application. These include

• Identify all the periodic threads in the application. Low priority and non-periodic tasks will execute in the non-deterministic 30% CPU timeframe
• Identify interrupts that can be treated as periodic
• Assign periods to threads and interrupts
• Assign execution times to the threads and interrupts
• Start by assigning the threads and interrupts that execute the most frequently with the highest priorities
• Use a spreadsheet with the RMA to determine if the threads and interrupts are schedulable
• Adjust the priorities based on the RMA until all threads can meet their deadlines

When performing an analysis on threads for an SSP application, beware that some frameworks have internal threads! For example, the audio playback framework has an internal thread with a preset priority that would be easy for developers to overlook if they did not know it existed. The best way to identify these internal threads is to check the documentation for frameworks in the application and look for a Thread Priority property in the framework properties. An example can be seen below:

When an internal thread exists, developers need to review the documentation and datasheet to determine the frameworks requirements and add it into the RMA. Few things can be as dangerous as overlooking a thread in an analysis!

As a simple example, let’s say a developer has three tasks that need to execute as shown below:

Developers can first determine if scheduling their threads is even possible by summing the execution time divided by the period as shown below:

1/5 + 2/10 + 4/10 = 0.80

For three tasks, RMA shows that the CPU utilization must be:

U = 3(2^1/3 – 1) = 0.77976

In this case, 0.80 > 0.77976 which means that the threads will not be schedulable without optimizing the system. If the execution time for the Thread 1 could be decreased by 50%, the result would be 0.70 which is less than 0.77976. At that point, the developer would assign priorities starting with the thread that runs the most frequently (Thread 1) down to the least frequent thread (Thread 2).

Using RMS provides developers with a good starting point for determining thread priorities. The only way to truly know if deadlines are being met and that no issues exist is to test and monitor the system. In the next post, we will look at the TraceX tool and how it can be used identify all the threads in the application and spot potential issues with the real-time performance. Until next time,

Live long and profit!

Professor_IoT

Hot Tip of the Week

You can easily find any new Renesas Synergy™ Platform projects for your kit from the Synergy Tools and Kits page. For example, from https://www.renesas.com/en-us/products/synergy/tools-kits.html you can select Sample Code to see a list of all the sample code for that various kits. The list is sorted by date so the most recent items show up first. See if you can find the HMI Brushless DC (BLDC) Motor Controller – Application Project from Feb 13, 2017 near the top of the list.