Covered the whole of the ready-list walk in the time-slice rebalance

2026-09-20T03:27:30Z

When a thread's time slice expires the kernel moves it to the end of the ready list at its priority and walks the rest of that list looking for a thread to hand the core to, stopping at the first one it can use. The walk only runs to the end when every other thread at the priority is already the thread its own core is executing. Two tests reached that by accident of scheduling -- one in ten of twenty-five standalone runs -- so the arm read covered in twelve of fourteen CI runs and missed in two, which is neither a gap nor coverage. It needs more than one core in use, which is why nothing reaches it on purpose: with every thread mapped to core 0 alone there is one executing thread, and the walk stops at the first thread it looks at. A new test clears the core exclusions on three workers at one priority so they run one to a core, then asserts the arrangement instead of waiting for it. Two of the three ways out of the walk are ruled out before it runs, so the only early exit left is the one that hands the core over -- and that one overwrites the core's entry in the execution list, so the entry still holding the same thread afterwards means the walk ran to the end. The arrangement, the expiry and the check are held under one SMP protection, and the expiry is driven by calling the routine the timer interrupt calls, inside the protection the timer interrupt holds when it calls it. The arm is taken in 30 of 30 standalone runs against 10 of 25 before, and the test is green in 50 consecutive runs in each of the eight configurations. It is a tx_thread_ construct in a timer batch, deliberately: it belongs to a batch that closed two steps ago and no remaining batch would reach it. Assisted-by: Claude Code (Opus 5)

threadx.git/test/smp/regression/threadx_thread_time_slice_walk_test.c, branch v6.4.1_cert

Covered the whole of the ready-list walk in the time-slice rebalance