threadx.git/test/smp/regression/threadx_thread_priority_change.c, branch v6.5.2.202603_rel

Stopped the thread priority change test leaving core 0 to a finished thread (#647)

2026-08-20T12:52:06Z

The SMP suite has been failing on threadx_thread_priority_change since 30 June. The test reports SUCCESS and the process then never exits, so ctest kills it at the thousand second timeout, twice, and the log carries nothing past the result line. Instrumenting the harness teardown produced the state at the hang: last stage reached: test_control_return: control thread resume returned _tx_thread_preempt_disable: 0 core 0: current=thread 0 execute=thread 0 thread test control thread state=0 priority=0 threshold=0 core_control=1 thread thread 0 state=1 priority=0 threshold=0 inherit=0 Core 0 is held by a thread in state 1, TX_COMPLETED, while the control thread sits in state 0, TX_READY, at priority 0. The Linux SMP scheduler fills a core only when _tx_thread_current_ptr for it is null, and clears that pointer only for a thread carrying a deferred preemption, which thread 0 is not. So core 0 can never be handed on, and with TX_THREAD_SMP_ONLY_CORE_0_DEFAULT and TX_SMP_NOT_POSSIBLE the control thread has nowhere else to go. The scheduler re-reads the same state every two milliseconds for as long as it is allowed to. What put thread 0 at priority 0 is the last thing this test does: thread_0.tx_thread_inherit_priority = 0; _tx_thread_smp_simple_priority_change(&thread_0, 16); with the stated intent of reaching the branch where the new priority is below the inheritance priority. Zero cannot reach that branch, because 16 is not less than 0. The other branch runs instead, and that branch assigns the inheritance priority as the thread's priority while the code after it links the thread into the list for the new priority regardless. Thread 0 therefore came away claiming priority 0 while living in the priority 16 list. Both halves of that hurt. Priority 0 ties with the control thread, so resuming the control thread raised no preemption and left the execute pointer alone. The mismatch between the recorded priority and the list the thread is linked into then means that completing thread 0 removes it from a list it was never in, leaving core 0 pointing at it for good. Give the inheritance priority a value above the new one, which is what the branch the comment names actually requires, and put it back to TX_MAX_PRIORITIES afterwards so nothing downstream reasons about an inheritance that is not there. Hold protection across the call as well: this is an internal routine that expects it, and it was being called in the open. Measured before and after by printing the thread's state at the point the test reports success. With the inheritance priority at 0 it is priority 0 threshold 0, matching the hang above, on every run. With it above the new priority it is priority 16 threshold 16, which agrees with the list the thread is linked into, and resuming the control thread preempts core 0 the ordinary way. All five SMP configurations pass 110 of 110 at the parallelism CI uses. The comparison in _tx_thread_smp_simple_priority_change deserves a second look on its own account. When its else branch runs, the thread's recorded priority and the list it is linked into disagree by construction. Only this test is known to reach that branch, by supplying an inheritance priority that cannot arise in ordinary operation, so nothing here claims a defect in shipped paths. Co-authored-by: Claude Opus 5 (1M context)

Bounded the wait in the thread priority change regression tests (#640)

2026-08-18T21:01:26Z

Both copies of this test, the SMP one and the non-SMP one, install an interrupt handler and then spin until it clears a flag: test_isr_dispatch = test_isr; do { ... } while (test_isr_dispatch); The handler clears that flag only on a narrow window: thread 3 at priority 6, ready, and not yet at the head of its priority list, which exists only part way through a priority change. If an interrupt never lands inside that window, the loop never ends. That is what has been failing in CI. The SMP suite has been red since 30 June, and this test times out in three of the last four failing runs, always in a stack-checking configuration. The evidence that it is a hang rather than slow work: the test carries no per-test timeout property, so ctest's --timeout 1000 applies, and locally the test finishes in 0.12 seconds with a worst case of 0.29 over thirty runs. Nothing turns that into more than a thousand seconds. It also survived --repeat until-pass:2, so it hung twice in succession. The TX_NOT_INTERRUPTABLE path in the same handler already stops after a fixed amount of work. Only the interruptable path, which is the one the failing configuration uses, had no protection. Cap the loop and clear the handler on the way out. When the window is not reached the test says so and still passes: not reaching it is a gap in what this run covered, not a fault in the code under test, and failing would report a defect that does not exist. The counters are left alone so the checks that follow keep their previous meaning. The cap is 100000 attempts. An exhausted cap takes about 60 seconds, measured, and a successful run takes 0.12 seconds, which puts the usual cost around two hundred attempts and leaves the cap roughly two orders of magnitude clear of it. That is wide enough not to lose coverage on a slower machine, while replacing a timeout that says nothing with a message that says what happened. Not reproducible here, which fits the diagnosis rather than contradicting it: on sixteen cores the window is hit almost at once. Thirty sequential runs, two hundred at parallelism thirty-two, sixty pinned to two CPUs, forty pinned to one, and three full-suite passes at the parallelism CI uses all came back clean. The defect is the reliance on the window, not any particular machine. Verified with the window deliberately made unreachable: before this change the test runs until it is killed, and after it exits in about a minute reporting that the window was not reached. The full SMP suite passes 110 of 110 at CI's parallelism.

Added copyright headers to files missing them

2026-06-06T19:48:06Z

Applied the standard MIT license header to all project-owned C, header, assembly, shell, and Python files that were missing a copyright notice. Third-party, toolchain startup, and auto-generated files were excluded. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Updated copyright headers and version number constants (#509)

2026-03-05T09:46:30Z

* Updated version number constants * Removed revision history from all files * Added Eclipse ThreadX contributors' copyright header

Release ThreadX regression system

2023-04-04T09:40:54Z