Reduced the byte pool owner change test to a single claim thread

2026-09-20T17:30:13Z

The test put one claim thread on every core the test thread was not using, and waited for all of them to be claiming before it started searching. On a machine with fewer processors than the port simulates cores that is not a safe wait: the claim threads walk the pool holding the protection, so two of them can keep the third from making any progress, and the test reports the arrangement as never having arrived. One CI run in seven failed that way. One claim thread is all the construct needs. It asks whether the pool can change hands under a walk, and a single other core answers it; further claim threads spend most of their time contending with each other rather than with the thread under test. The walk count goes up from five to twenty to keep the margin the extra threads were providing. Between 360 and 1,320 changes of pool ownership per run over six runs in the two configurations that schedule it slowest, against the one the coverage needs, in 2.5 seconds. 129/129 in each of eight configurations with retries disabled. Assisted-by: Claude Code (Opus 5)

Covered the byte pool search retry when the pool changes owner

2026-09-20T17:10:47Z

Where the SMP byte pool search gives the protection up, it checks on taking it back whether the pool is still its own, and if not it delays, resets the walk and claims the pool again. Three branch outcomes and eight lines of that were never executed. The pool owner is written in six places, all of them kernel services, and none can run on the searching thread's own core while that thread is inside the walk, so the construct needs a second core in use. The existing contention test does not reach it because its pool is too small to open the window at all: the protection is only given up once per multiple block search limit. A new test keeps the test thread on its own core and puts one claim thread on each of the others, each making the same unsatisfiable request and so walking the same pool. A claim thread is then usually already holding the protection when the test thread reaches a window, which is the state the construct is written against. The test waits for every claim thread to be mapped and claiming before it starts searching, rather than sleeping a fixed number of ticks, because how long the rebalance takes varies by configuration. It asserts the arrangement rather than the retry, which restores the owner the walk had already set and leaves nothing a test can read. Three outcomes and eight lines, measured at 48,971 changes of owner in a run of 2.6 seconds. This is the second test in the suite that needs more than one core. 129/129 in each of eight configurations with retries disabled, and sixty standalone repeats clean in the three configurations that schedule it slowest. Assisted-by: Claude Code (Opus 5)

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

Reduced the byte pool owner change test to a single claim thread

Covered the byte pool search retry when the pool changes owner