summaryrefslogtreecommitdiff
path: root/common_modules/module_manager/src/txm_module_manager_thread_create.c
diff options
context:
space:
mode:
authorFrédéric Desbiens <[email protected]>2026-08-20 08:49:43 -0400
committerGitHub <[email protected]>2026-08-20 08:49:43 -0400
commit4d9ce418451cca88851c8e255a3bbb3703ad47ab (patch)
tree10f8afd46469606818cf44afe5f3af22ae0a77eb /common_modules/module_manager/src/txm_module_manager_thread_create.c
parent7928dc4268028961eeedfc3751c637ed232428d7 (diff)
Gave the wait abort ISR test a budget instead of an open-ended wait (#644)
threadx_thread_wait_abort_and_isr_test waits for an interrupt to land while the preempt disable flag is set, and waits for it ten times, twenty in the SMP copy, with no bound on how long that takes. The handler in the same file already says what can go wrong: It is possible for this test to get into a resonance condition in which the ISR never occurs while preemption is disabled and perturbs its own duration to break out of it. That helps but guarantees nothing, and if the resonance holds, the loop does not end. It is also, by a wide margin, the most expensive thing in either suite. Run one test at a time in CI it took between 148 and 726 seconds per configuration: 1936 seconds of the ThreadX suite's 2209, against 273 seconds for the other ninety five tests together. Nothing else in the suite is within two orders of magnitude of it. The budget is in wall clock seconds, not ticks. That distinction turned out to matter. A tick is delivered only when the port's timer thread gets to run, so the simulated clock falls behind real time under load or under coverage instrumentation, and never makes the loss up. A first attempt bounded the wait at 20000 ticks, nominally 200 seconds, and failed to stop a run that took 726 seconds, because fewer than 20000 ticks had gone by. tx_time_get() cannot bound elapsed time here; time() can. A run that falls short says how many windows it reached rather than going quiet, and the check after the loop is untouched. That check compares semaphore bookkeeping which holds whatever number of windows were hit, so it still means exactly what it did before. Hitting the race a few times rather than ten is a smaller loss than it looks: the value is in reaching the window at all, and the later hits repeat what the first ones established. Verified by forcing the budget to 3 seconds, where the test stops after 3.14 seconds of wall clock and reports reaching 0 of 10 windows, with the following check intact. At 120 seconds both suites pass every configuration run serially. Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Diffstat (limited to 'common_modules/module_manager/src/txm_module_manager_thread_create.c')
0 files changed, 0 insertions, 0 deletions