ThreadX^® Performance Analysis

By William Lamie, Express Logic, Inc.

1. Overview

ThreadX^® is a high-performance multitasking solution for time-critical, deeply embedded applications. It's simple and straightforward design provides developers with a high-performance and scaleable solution that is extremely easy to use. This ease of use manifests itself over the entire development cycle - from initial design and implementation through pre-production tuning and verification.

The focus of this document is on ThreadX performance analysis. Such analysis is necessary in order to debug application deadline problems. It is also very useful in pre-production system tuning and verification. As mentioned before, ThreadX provides developers a simple and easy to use multitasking solution. Because of this, ThreadX performance analysis is quite straightforward. The following sections describe performance analysis from a non-intrusive perspective and one that requires very slight modifications to the context switching code of ThreadX.

2. Non-Intrusive Performance Analysis

As the name implies, this type of performance analysis requires no additional code on the target system. This is certainly a preferred method because intrusive methods always have some effect on the timing of the target system. The downside to the non-intrusive approach is that it requires additional development hardware (a logic analyzer) and minimal effort setting up triggers and data captures.

2.1 Logic Analyzer Analysis

With a logic analyzer it is quite easy to track thread execution. This is true because of the simplicity of the ThreadX design. When a thread is executing, the address of it's control block resides in the variable _tx_thread_current_ptr. If this variable is NULL, no thread is running and the system is idle.

Interrupts present the only exception to the current thread pointer rule. When the variable _tx_thread_system_state is non-zero, interrupt processing is in effect. The following set of rules apply to thread execution:

• Thread execution starts when _tx_thread_current_ptr transitions from NULL.
• Thread execution ends when _tx_thread_current_ptr transitions back to NULL.
• If during thread execution the value of _tx_thread_system_state becomes non-zero, the time between that time and when it goes back to zero should be associated with interrupt processing instead of thread or idle system processing.

Using these simple rules, it is quite easy to setup a logic analyzer to track the performance of an individual thread (look for _tx_thread_current_ptr set to a specific thread control block address). It is also quite easy to track the execution of all threads in the system. Tracking idle time and interrupt processing time is also fairly straightforward.

2.2 Schedule Count

With a source-level debugger, it is quite easy to get a feel for which threads are being scheduled the most in ThreadX. Each time a thread is scheduled a counter is incremented in its control block. The name of the counter is tx_run_count. This counter is especially useful in detecting excessive preemption conditions. For example, if a lower-priority thread is interacting with many higher-priority threads, it is possible to introduce unnecessary thread scheduling in the system. In such cases the thread run count will be much greater than the normal service call suspension rate of the thread. Fixing this problem might be as simple as setting the preemption-threshold of a thread to a different value at creation.

3. Intrusive Analysis

Because its simplicity, it is quite easy to track the execution time of each thread under ThreadX. A small amount of assembly code can be added inside of the ThreadX scheduler, system return function, and interrupt management functions to maintain the execution time of each thread. Interrupt execution time can be tracked in a similar manner. System idle time can be calculated from the total time elapsed minus interrupt processing time and the sum of all thread execution.

Implementing this in ThreadX requires a dedicated high-resolution target timer. The following areas of ThreadX require modifications to track thread and interrupt execution time:

File TX_TS.S TX_TSR.S TX_TCS.S TX_TCR.S

Function _tx_thread_schedule _tx_thread_system_return _tx_thread_context_save _tx_thread_context_restore

Of course, the down-side of this approach is that it adds additional overhead to the application. The overhead induced is probably on the order of 5% per context switch or interrupt.

Any execution tracking code of this nature should be done in a manner that facilitates their easy removal.

4. Summary

Although the techniques mentioned in this document are not integrated with a flashy Windows interface, they are very effective and easy to understand and use. Furthermore, the non-intrusive approaches described in section 2.1 enable developers to analyze system performance of their actual production software running at full speed - which is really the most important.

At Express Logic customer support is as important as the technical merits of ThreadX. We will be glad to assist any of our customers that are interested in the performance analysis features mentioned in this document.

Bill Lamie has 18 years of experience as an embedded software engineer. He is the principal architect of several commercial kernels, including ThreadX®, the high-performance kernel offered by Express Logic, Inc.