Covered the block allocate trace update on both of its paths

2026-09-20T17:10:46Z

The block allocate records its event, saves the entry and its time stamp, and comes back to write the address it handed out into that entry if nothing has overwritten it. There are two such regions, one on the path that finds a block immediately and one on the path that suspends. Nothing had ever run the service with tracing enabled, so the entry pointer checks stood at one of two with only the false arm taken and the time stamp comparisons at zero of two. A new test uses two threads and three passes: a plain successful allocate, a suspending allocate handed a block with its entry intact, and the same handover with the trace buffer written all the way round in between so the service correctly declines to update. The helper runs at a higher priority than the test thread, so every handover is a preemption rather than something that waits for a tick, and both threads keep the suite's default core mapping so only one of them runs at a time. Seven of the eight outcomes and all seven lines. The remaining one is the false arm of the immediate path's comparison, whose window is one unbroken SMP protection with no trace insert in it. 129/129 in each of eight configurations with retries disabled. Assisted-by: Claude Code (Opus 5)

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

Covered the block allocate trace update on both of its paths