<feed xmlns='http://www.w3.org/2005/Atom'>
<title>threadx.git/test/tx/regression/threadx_thread_trace_test.c, branch v6.4.1_cert</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/threadx.git/atom/test/tx/regression/threadx_thread_trace_test.c?h=v6.4.1_cert</id>
<link rel='self' href='http://cgit.235523.xyz/threadx.git/atom/test/tx/regression/threadx_thread_trace_test.c?h=v6.4.1_cert'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/'/>
<updated>2026-09-15T16:09:33Z</updated>
<entry>
<title>Covered the thread services' trace inserts in every system state</title>
<updated>2026-09-15T16:09:33Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-15T16:09:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=6140dba5d719d26434c005f51f553e6d33657dd0'/>
<id>urn:sha1:6140dba5d719d26434c005f51f553e6d33657dd0</id>
<content type='text'>
Every thread service carries one TX_TRACE_IN_LINE_INSERT, and gcov scores twelve
branch outcomes for the macro. Seventeen of those inserts sat between one and
nine of twelve, because exactly one test in the suite ever turns tracing on and
it does not drive the thread API. The code runs -- the sites are hit hundreds of
thousands of times -- but tracing is never enabled when it does.

The new test follows the shape the queue subsystem established. It enables
tracing and walks all sixteen services once per condition the macro
distinguishes: in thread context, in interrupt context from the test ISR
dispatch, with the system state forced to TX_INITIALIZE_IN_PROGRESS and again to
the value an interrupt presents, with the thread and internal event classes
filtered out, and across a buffer wrap with and without a buffer-full
notification registered.

Three things are specific to this subsystem rather than inherited from the queue
test.

The scheduler's inserts sit behind the published ones. A resume writes an API
event and then _tx_thread_system_resume writes an internal event of its own, so
positioning the buffer one entry short of its end puts the API insert on the
boundary and never the scheduler's. The wrap pass therefore drives the resume
and the suspend twice, positioned one entry short and then two.

The scheduler also updates the entry it wrote, once it knows which thread runs
next, and only if the timestamp says nothing overwrote it in between. That
update is unreachable unless a resume actually preempts while tracing is on, so
the test ends with a pass that resumes a higher-priority thread and takes the
processor back from it four times. The three regions of
_tx_thread_system_suspend and the two of _tx_thread_system_resume are reached
this way; what is left uncovered in them is the arm where the timestamp differs,
which needs a second event inserted inside a window the kernel holds interrupts
off across.

The sleep service tests the system state itself, ahead of its own insert, and
refuses every caller that is not a thread. Its insert is therefore only ever
reached at system state zero and stops at nine of twelve. Neither the published
entry point nor the internal one can reach the other three.

A thread's lifecycle does not close on itself the way a queue's does: a reset is
only legal from the terminated state, which a reset does not leave the thread
in. So the reset is driven against a second scratch thread that the service
terminates again on its way out, after its own insert has run, and the first
scratch thread is created and deleted once per pass as the queue was.

Merged coverage over the six build configurations rises from 3927/4627 branches
to 4097/4627, with lines at 4300/4339. Every thread trace insert but the sleep
is now at twelve of twelve. The gates go to 99.00 and 88.00, below the measured
figures by the margin the resume-from-ISR variance needs: two clean runs agree
exactly on lines and differ by one branch outcome.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
